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ABSTRACT 


This  thesis  extends  the  multi- computer  real-time 
executive,  MCORTEX.  The  multiple  cluster  system  RTC*  (Real 
Time  Cluster  Star) ,  consisting  of  clusters  of  single  board 
computers  (INTEL  iSBC  86/12A),  which  are  connected  via  an 
Ethernet  Local  Area  Network,  serves  as  a  hardware  basis  for 
the  implementation  of  extended  MCORTEX. 

The  extension  upgrades  MCORTEX  to  system-wide 
synchronization  and  general  data  communication  between  any 
processes  in  the  system.  An  intercluster  shared  memory  model 
is  developed,  that  partially  replicates  intracluster  shared 
memory,  such  that  shared  data  replication  is  minimized  and 
the  system's  processing  speed  is  maximized. 

This  implementation,  by  transmitting  produced  shared 
data  to  all  consuming  clusters  as  soon  as  possible  after 
production,  guarantees  that  only  cluster  local  hits  occur  in 
the  system.  Shared  memory  space  is  used  efficiently  by 
transmitting  shared  data  to  consuming  clusters  only,  and  by 
the  ability  to  store  shared  data  contiguously  in 
intracluster  shared  memory. 
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I.  INTRODUCTION 

A.  DISCUSSION 

1 .  General 

The  goal  of  this  thesis  is  to  extend  the  existing 
version  of  the  distributed  multi-computer  real  time 
executive  (E-MCORTEX)  in  order  to  provide  systemwide 
interprocess  data  communication. 

The  existing  MCORTEX  version  was  provided  by  David 
Brewer  in  December  1984  [Ref.  1],  and  contributes  to  the 
research  work  done  by  the  AEGIS  Modeling  Group  at  the  Naval 
Postgraduate  School  (NPS). 

The  objective  of  this  project  group  is  research  on 
time  critical  processing  required  by  modern  anti-air  warfare 
(AAW)  systems.  The  project  group  chose  the  AN/SPY- lA  phased 
array  radar  processing  unit  of  the  AEGIS  weapon  system  due 
to  its  challenging  time  critical  processing  demands.  A 
further  fundamental  objective  of  the  AEGIS  Modeling  Group  is 
to  use  off  the  shelf  components  within  the  AEGIS  weapons 
system  as  a  low  cost  approach,  and  to  upgrade  reliability  of 
the  system  by  replacing  the  AN/UYK-7  central  computer  of  the 
AN/SPY-lA  system  by  distributed  computing  power.  Rapid 
repair  turnaround  and  low  component  replacement  cost  in  the 
system  in  case  of  failure,  and  graceful  degradation  of  the 
system  are  of  utmost  importance  especially  for  military 
applications . 

The  available  lab  system  at  NPS  is  made  up  of  single 
board  computers  building  MULTIBUS  clusters  which  are 
connected  via  an  Ethernet  Local  Area  Network. 

2 .  Systems  Architecture 

The  lab  system's  hardware  configuration  shown  in 
Figure  1.1  consists  of  two  clusters  with  up  to  four  Intel 
iSBC  86/12A  single  board  computers  (SBC)  in  a  cluster  at  the 
present  time.  A  MULTIBUS  serves  as  the  interconnection 
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medium  for  all  cluster  elements,  i.e.  besides  the  SBC  s ,  a 
hard  disk  drive,  two  extra  memory  boards,  and  an  interLAN 
NI3010  Ethernet  Communication  Controller  Board  (ECCB).  The 
ECCB  provides,  via  a  transceiver,  the  cluster's  connection 
to  the  Ethernet. 

With  the  MULTIBUS  as  an  intracluster  bus  and  the 
Ethernet  as  an  intercluster  bus  the  system's  configuration 
looks  similar  to  Carnegie  Mellon's  Cm*  [Ref.  2].  Due  to  its 
goal  to  serve  time  critical  applications  in  a  real  time 
environment  the  AEGIS  lab  system  is  known  as  Real-Time 
Cluster  Star  (RTC*). 

The  system's  software  configuration  shown  in  Figure 
1.2  consists  of  a  MCORTEX  kernel  on  every  SBC,  MCORTEX 
global  data  on  one  extra  memory  board,  known  as  Common 
Memory,  and  Shared  Memory  on  the  second  extra  memory  board 
in  every  cluster.  Besides  the  MCORTEX  kernel,  also  the 
CP/M-86  operating  system  and  DDT-86  are  available  in  local 
RAM  of  every  SBC,  and  the  user  area  provides  space  for 
application  programs.  The  CP/M  Multiuser  area  is  kept  on  the 
Common  Memory  board,  while  Shared  Memory  houses  user  shared 
data  and  some  system's  shared  data. 

SBC  1  in  every  cluster  is  dedicated  to  a  systems 
program  known  as  the  system  device  handler  and  packet 
processor  (called  a  driver  in  the  following).  Part  of 
Shared  Memory  is  used  as  a  data  exchange  buffer  between  any 
SBC  in  the  cluster  and  the  driver  board,  SBC  1,  for  Ethernet 
transmission  requests.  Another  part  serves  as  data  exchange 
buffer  between  the  driver  board  and  the  ECCB  for  handing 
over  messages  which  are  to  be  transmitted  and  messages  which 
have  been  received. 

The  distributed  MCORTEX  kernels  provide  the 
multiprocessing  capability  of  the  system.  System  processes 
and  user  processes  share  the  CPU  of  a  respective  SBC.  David 
Brewer  gives  an  in  depth  discussion  of  the  interrelationship 
and  the  scheduling  of  processes. 
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The  process  synchronization  is  accomplished  using 
event counts  and  sequencers  as  developed  by  Reed  and  Kanodia 
[Ref.  3].  Eventcounts  synchronize  all  processes,  those 
running  on  the  same  board  as  well  as  those  running  on 
different  boards  in  the  same  cluster  as  well  as  those 
running  on  boards  in  different  clusters. 

It  is  important  to  recognize  that  eventcounts  are 
also  data,  even  though  a  special  kind  of  data. 

3 .  Specific 

A  typical  application  situation  for  systems  like 
RTC*  is  time  critical  gathering  of  data  by  real  time  sensors 
(e.g.  radar),  processing  these  data  in  the  context  of 
information  gathered  by  other  sensors,  and  executing 
specific  algorithms  in  order  to  produce  data  that  are 
consumed  by  effectors  (e.g.  missile  launchers). 

Under  the  realistic  assumption  that  sensors  and 
effectors  are  locally  distributed  and  that  sensor-effector 
coupling  or  grouping  must  be  kept  flexible  for  the  sake  of 
weapon  system  survivability,  it  is  obvious  that  the 
different  processing  modules  cannot  be  kept  together  close 
enough  in  order  to  use  shared  memory  in  the  conventional 
sense. 

B .  BACKGROUND 

A  series  of  theses  starting  with  one  by  W.J  Wasson,  June 

1980,  which  defined  the  detailed  design  of  MCORTEX  based  on 
MULTICS  and  the  use  of  eventcounts  [Ref.  4],  developed  a 
highly  modular  system,  hardwarewise  and  softwarewise ,  using 
commercially  available  components,  that  guarantee  low  cost, 
availability,  and  reliability.  D.K.Rapantzikos ,  March  1981, 
provided  initial  implementation  [Ref.  5],  E.R.  Cox,  December 

1981,  refinement  [Ref.  6],  and  S.G.  Klinefelter,  June  1982, 
dynamical  interaction  with  the  operating  system  during 
execution  [Ref.  7]. 

W.R.  Rowe,  June  1984,  put  the  multiuser  CP/M-86 
operating  system  under  control  of  MCORTEX  [Ref.  8],  and 


finally  D.J.  Brewer,  December  1984,  extended  MCORTEX  to  a 
multicluster  system  without  shared  memory,  using  Ethernet  as 
cluster  interface. 

The  system’s  functioning  was  shown  for  the  extended 
MCORTEX  version  up  to  the  level  of  systemwide  process 
synchronization  using  distributed  eventcounts  in  a 
multicluster  environment.  Even  though  eventcounts  are  data 
also,  and  communicating  eventcounts  is  shared  data 
communication,  this  special  shared  data  communication  lacks 
the  ability  of  user  shared  data  distribution  over  the  total 
system. 

This  thesis  tackles  this  important  step. 

C.  STRUCTURE  OF  THE  THESIS 
The  goals  of  this  thesis  are: 

1.  To  extend  the  existing  MCORTEX  version,  that  provides 
process  synchronization  and  single  cluster 
inter-systemprocess  data  communication  using  an  intracluster 
shared  memory,  to  multicluster  general  inter-process  data 
communication  in  an  Ethernet  Local  Area  Network  environment. 

2.  To  develop  an  appropriate  model  for  intercluster 
shared  memory  to  be  used  in  the  system. 

3.  To  accomplish  the  extension  without  changing  the 
MCORTEX  kernel,  but  modifying  PL/I-86  modules  only. 

Chapter  I  discusses  the  objective  of  the  AEGIS  Modeling 
Group  at  the  Naval  Postgraduate  School,  gives  an 
introductory  system's  overview,  a  brief  development  history 
of  the  system,  and  outlines  the  goals  of  this  thesis. 

Chapter  II  discusses  three  different  approaches  studied 
in  developing  the  concept  of  intercluster  shared  memory  for 
RTC*,  and  the  reasoning  that  lead  to  the  decision  for  the 
chosen  model. 

Chapter  III  presents  the  organization  of  intracluster 
shared  memory,  the  use  of  the  user  shared  data  area,  and  the 
intracluster  data  flow. 


Chapter  IV  provides  an  in  depth  presentation  of  the 
development  and  realization  of  intercluster  data  sharing  in 
RTC*. 

Chapter  V  summarizes  the  current  state  of  the  system 
and  addresses  possible  future  enhancements. 
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II.  ORGANIZATION  OF  INTERCLUSTER  SHARED  MEMORY 
A.  SHARED  MEMORY  MODELS 

In  developing  the  concept  of  intercluster  shared  memory 
for  RTC*,  three  different  approaches  were  studied: 

1)  no  replication  of  intracluster  shared  memory, 

2)  total  replication  of  intracluster  shared  memory,  and 

3)  partial  replication  of  intracluster  shared  memory. 

The  logical  structures  of  these  approaches  are  shown  in 
Figure  2.1. 

1.  ^  Replication 

This  model  views  the  intercluster  shared  memory  as 
the  sum  of  individual  intracluster  shared  memories  of  all 
clusters  available  in  the  system.  This  is  very  similar  to 
the  approach  chosen  for  Cm*. 

Every  shared  data  item  is  kept  only  once  in 
intercluster  shared  memory,  normally  in  the  intracluster 
shared  memory  of  the  home  cluster  of  the  producing  process. 
Consuming  processes  have  to  go  through  the  vari  is  bus 
hierarchies  of  the  system  in  order  to  access  the  respective 
item  at  the  time  when  consumption  is  to  start.  Apparently 
this  is  a  very  time  consuming  effort  if  the  respective  data 
item  is  not  resident  close  to  the  consuming  process.  Close 
in  this  context  refers  to  being  located  in  shared  memory  of 
the  consuming  process'  home  cluster.  In  terms  of  time 
efficiency  for  this  model,  the  only  reasonable  solution  for 
this  situation  is  to  put  producing  and  consuming  processes 
as  close  together  as  possible  in  order  to  increase  the  rate 
of  cluster  local  hits. 

The  space- time  dilemma  becomes  obvious.  In  terms  of 
space,  this  approach  is  the  most  efficient  one,  because 
there  exist  no  duplications  of  any  data  item  in  the  whole 
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system.  The  intercluster  shared  memory  space  is  equal  to  the 
sum  of  all  intracluster  shared  memory  spaces  in  the  system. 

However,  if  we  accept  the  fact  that  memory  becomes 
cheaper  and  cheaper  every  year  due  to  development  of 
technologies  that  put  more  and  more  memory  space  on  a  chip, 
then  we  could  afford  to  replicate  data  in  different  memories 
of  the  system  in  order  to  increase  the  number  of  cluster 
local  hits,  or  even  to  ensure  that  only  local  hits  happen  in 
the  system.  This  leads  to  the  second  model  of  intercluster 
shared  memory. 

2 .  Total  Replication 

The  opposite  extreme  of  no  replication  is  total 
replication  of  all  shared  memory,  i.e.  every  intracluster 
shared  memory  keeps  all  shared  data  items  and  so 
intercluster  shared  memory  consists  of  as  many  copies  of 
intracluster  shared  memory  as  there  are  clusters  in  the 
system.  Due  to  the  necessity  that  all  intercluster  shared 
memory  has  to  fit  in  every  intracluster  shared  memory,  the 
available  space  for  intercluster  shared  memory  is  equal  to 
the  space  of  the  smallest  intracluster  shared  memory  of  any 
cluster  in  the  system.  Therefore  it  must  be  ensured  that  the 
smallest  intracluster  shared  memory  is  large  enough  to  keep 
all  shared  data  items  needed  in  the  system. 

This  model  makes  sure  that  only  cluster  local  hits 
occur  in  the  system,  and  that  every  consuming  process  finds 
every  data  item  in  shared  memory  of  its  home  cluster.  This 
seems  to  be  a  very  time  efficient  approach  that  suits  the 
demand  of  having  data  as  close  as  possible  to  the  producer 
and  the  consumer  as  well. 

A  major  problem  with  this  approach  however  is  the 
increased  overhead  in  maintaining  and  updating  of  shared 
data  items  that  are  never  used  at  a  certain  cluster.  This 
overhead  especially  consists  of  traffic  on  the  systems  buses 
and  processing  time  of  the  hosts  at  the  interfaces  between 
clusters  and  transmission  medium.  This  traffic  overhead 


slows  down  the  data  distribution  so  that  it  takes  longer  for 
data  to  be  available  at  the  consuming  process'  cluster  for  a 
local  hit  there. 

The  compromise  is  a  combination  of  these  first  two 
models,  where  only  necessary  replication  of  data  is  done. 

3 .  Partial  Replication 

In  this  model  every  cluster  maintains  shared  data 
only  if  those  data  are  used  at  a  specific  cluster,  i.e.the 
producing  and  the  consuming  clusters  only  keep  a  copy  of 
respective  data  items,  no  superfluous  information  is 
maintained  and  there  is  no  superfluous  traffic  on  the 
transmission  medium  and  the  system  buses.  The  intercluster 
shared  memory  in  this  approach  is  equal  to  the  union  of  all 
individual  intracluster  shared  memories  in  the  system  and 
only  the  intersections  are  replicated.  There  can  be 
different  intersections  between  different  cluster  groups  in 
the  system.  This  approach  is  the  most  efficient  one  in 
terms  of  space  and  time.  The  traffic  on  the  transmission 
medium  and  the  system  buses,  and  the  amount  of  processing 
time  needed  for  data  exchange  is  kept  to  a  minimum.  Also,  as 
in  the  total  replication  approach,  only  cluster  local  hits 
will  occur. 

The  overall  policy  is  to  transmit  shared  data  to 
all  consuming  clusters  as  soon  as  possible  after  production, 
and  to  transmit  those  data  to  consuming  clusters  only. 

This  approach  seems  to  be  the  most  adequate  one  for 
a  distributed  real  time  system,  as  it  reflects  the  optimal 
compromise  in  terms  of  speed  , space,  and  update  overhead. 

Intercluster  shared  memory  by  partial  replication  of 
intracluster  shared  memories  was  therefore  chosen  for 
implementation  in  RTC*. 


III.  ORGANIZATION  OF  INTRACLUSTER  SHARED  MEMORY 


A.  CLASSES  OF  SHARED  DATA 

Looking  closer  at  shared  data,  we  realize  that  there  are 
different  classes  of  shared  data  used  in  the  system.  Some 
data  is  shared  among  processes  on  the  same  board  only,  some 
is  shared  among  processes  on  different  boards  in  the  same 
cluster,  and  some  is  shared  among  processes  in  different 
clusters . 

It  was  decided  to  keep  all  shared  data  on  special  memory 
boards,  even  though  some  of  the  data  is  produced  and 
consumed  on  the  same  board.  To  protect  system's  data  used  by 
the  operating  system,  these  data  items  are  stored  in  Common 
Memory,  which  is  beyond  the  reach  of  user  data  memory, 
called  Shared  Memory. 

All  MCORTEX  global  data  are  maintained  in  Common  Memory. 
Every  cluster  has  one  Common  Memory  where  all  MCORTEX  global 
data  needed  in  the  respective  cluster  is  kept .  Brewer 
describes  the  logical  organization  of  Common  Memories.  Due 
to  the  fact  that  eventcounts  are  used  for  intracluster  and 
intercluster  process  synchronization,  some  of  these 
eventcounts  are  replicated  in  more  than  one  cluster. 

/  It  must  be  recognized  that  there  exist  system's 

eventcounts  in  every  cluster,  e.g.  ERB_READ  and  ERB_WRITE. 
These  are  used  strictly  cluster  internally  and  do  not  belong 
to  the  intersection  of  intercluster  Common  Memory.  These 
system  eventcount  have  the  same  name  in  every  cluster,  but 
their  respective  values  are  never  distributed  over  the 
system.  Only  user  eventcounts  that  are  used  in  more  than  one 
cluster  are  distributed  and  therefore  replicated  in 
respective  clusters. 


B.  SYSTEM  SHARED  DATA 


A  similar  situation  exists  in  Shared  Memory.  There  are 
three  data  items  in  Shared  Memory  which  are  used  exclusively 
within  the  cluster: 

1)  the  Ethernet_Request_Block, 

2)  the  Transmit_Data_Block,  and 

3)  the  Receive_Data_Block. 

These  are  data  items  shared  between  the  driver  residing 
on  SBC  1  and  either  MCORTEX  kernels  on  other  boards  or  the 
ECCB.  These  system's  data  items  are  needed  to  establish 
cluster  external  communication.  Information  needed  by  the 
driver  about  outgoing  and  incoming  messages  has  to  be 
communicated  via  Shared  Memory,  because  it  is  not  possible 
to  access  local  memory  of  any  SBC  from  outside  the  board. 

As  is  true  for  system  eventcounts  in  Common  Memorv, 
these  three  system  shared  data  items  are  also  used  strictly 
cluster  internally  and  do  not  belong  to  the  intersection  of 
intercluster  Shared  Memory,  even  though  they  have  the  same 
names  in  every  cluster.  Only  user  shared  data,  that  are 
shared  in  more  than  one  cluster  are  distributed  and 
therefore  replicated  at  respective  clusters. 

As  described  by  Brewer,  the  Ethernet  Request  Block,  the 
Transmit  Data  Block,  and  the  Receive  Data  Block  reside  in 
this  order  in  the  lower  part  of  Shared  Memory  at  addresses 
lOOOOH,  10078H,  and  10666H  respectively.  The  User  Shared 
Data  Block  starts  at  address  10C58H  and  goes  up  to  17FFFH  as 
the  highest  address  in  Shared  Memory  in  the  present 
implementation  of  RTC*. 

C.  USER  SHARED  DATA 

Shared  data  items  are  basically  interfaces  between 
different  processes.  Processes  communicate  via  these  shared 
data.  It  is  therefore  important  to  agree  on  the  name,  size, 
and  structure  of  shared  data  used  by  different  programmers 
for  different  process  modules.  This  agreement  must  be 
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accepted  by  all  programmers  of  any  system  module  and  can  be 
thought  of  as  reached  under  the  guidance  of  a  lead 
programmer. 

An  individual  programmer  can  still  use  any  other  private 
name  and  structure  for  some  variable,  as  long  as  he  or  she 
ensures  that  communication  with  any  other  module  is  done 
using  the  agreed  upon  name  and  structure. 

1.  Organization  of  Shared  Data 

Shared  data  items  are  organized  as  circular  queues 
of  structures,  where  the  actual  item  is  a  structure  and  the 
queue  serves  as  buffer  between  producers  and  consumers.  This 
is  true  for  user  shared  data  and  system  shared  data  as  well. 

While  system  shared  data  items  have  fixed  predefined 
structures  and  queue  lengths,  a  user  shared  data  item  can  be 
of  any  structure,  and  a  user  shared  data  queue  can  be  of  any 
length.  The  only  restriction  is  that  all  user  shared  data 
queues  needed  at  some  cluster  must  fit  together  into  the 
User  Shared  Data  Block  in  Shared  Memory  of  that  cluster. 

The  length  of  specific  data  queues  is  another 
important  issue  to  be  agreed  upon  by  all  programmers  using 
respective  shared  data  items.  The  chosen  queue  length 
depends  on  the  expected  average  input  and  output  rate  of  a 
specific  data  item  queue.  The  goal  is  to  reduce  or,  if 
possible,  to  avoid  idle  waiting  times  at  producing  processes 
due  to  a  filled  up  queue  caused  by  slow  consumption. 

As  mentioned  in  Chapter  II,  the  data  communicating 
version  of  RTC*  developed  in  this  thesis  will  use  the 
concept  of  partial  replication  of  Shared  Memory.  Therefore 
we  think  of  intercluster  Shared  Memory  as  the  union  of  all 
intracluster  shared  memory  blocks  that  contain  user  shared 
data.  Data  communication  is  only  possible  among  clusters 
that  actually  share  data  (i.e.  there  exist  an  intersection 
of  intracluster  Shared  Memories  of  those  clusters  and  the 
respective  shared  data  item  is  in  the  intersection) .  To  put 
it  another  way,  an  intersection  of  intracluster  Shared 


Memories  is  only  needed  if  processes  in  respective  clusters 
need  to  communicate.  If  intracluster  Shared  Memories  only 
keep  those  shared  data  items  needed  (produced  or  consumed) 
by  ^ome  process  in  the  cluster,  then  automatically  the 
minimum  intersection  and  therefore  the  least  duplicated  use 
of  memory  space  and  the  most  efficient  use  of  time  for 
maintaining  the  data  is  guaranteed. 

2 .  Storage  of  User  Shared  Data 

In  order  to  further  accomplish  efficient  use  of 
memory  space,  the  system  is  set  up  in  such  a  way,  that  user 
shared  data  queues  can  be  stored  at  any  address  in  the  User 
Shared  Data  Block  in  Shared  Memory.  There  must,  however,  be 
enough  space  available  between  the  starting  address  of  the 
queue  and  the  highest  possible  physical  memory  address 
(i.e.l7FFFH  in  the  present  implementation). 

This  flexibility  also  allows  for  contiguous  storage 
of  all  user  shared  data  and  thus  the  available  storage  space 
is  most  efficiently  used. 

The  same  data  item  can  reside  under  different 
addresses  in  different  clusters.  The  application  programmers 
do  not  have  to  worry  about  the  addresses,  they  refer  to  a 
specific  data  item  by  its  name.  The  lead  programmer  will 
take  care  of  assigning  addresses  to  shared  data  queues.  When 
and  how  this  is  done  will  be  discussed  in  Chapter  IV.  For 
now  it  should  suffice  to  realize  that  the  organization  and 
storage  of  user  shared  data  in  this  implementation  is  done 
with  the  least  duplication  of  data  items,  where  each  shared 
data  is  available  in  the  local  cluster. 

D.  RELATION  BETWEEN  SHARED  DATA 

An  important  relation  exists  between  system  shared  data, 
eventcounts  and  user  shared  data,  which  is  exploited  by  the 
driver  for  its  data  communication  task. 

The  system  internal  management  of  a  data  queue  is 
controlled  using  an  eventcount  <dataname>_IN  and  an 
eventcount  <dataname>  OUT.  These  eventcounts  have  to  be 


distributed  over  the  same  clusters  as  the  related  data  item, 
in  order  to  ensure  that  a  consumer  does  not  read  a  data  item 
before  it  is  in  the  queue,  and  a  producer  does  not  write  a 
new  item  into  an  already  used  slot  before  the  old  item  has 
been  consumed  by  all  its  consumers.  The  eventcount 
<dataname>_IN  tells  all  consumers  that  an  item  is  available, 
the  eventcount  <dataname>_OUT  tells  the  producer  that  a 
former  used  slot  is  available  for  new  data. 

1.  The  Ethernet  Request  Block 

Refer  to  Figure  3.1  for  the  following  discussion. 
The  system  shared  data  queue,  the  Ethernet  Request  Block 
(ERB)  is  filled  with  Ethernet  Request  Packets  (ERP) 
initiated  by  any  process  resident  at  the  cluster  when  it 
calls  for  an  update  of  the  value  of  an  eventcount  that  is 
also  needed  at  some  other  cluster. 

The  many  producers  of  Ethernet  Request  Packets  are 
kept  in  sequence  by  the  systems  sequencer  ERB_WRITE_REQIJEST , 
which  basically  is  a  ticket  machine  that  makes  sure  that 
only  one  packet  at  a  time  is  put  into  the  Ethernet  Request 
Block,  and  that  Ethernet  Request  Packets  are  put  in  on  a 
first  come  first  serve  basis.  The  only  consumer  of  Ethernet 
Request  Packets  is  the  driver  on  SBC  1. 

An  Ethernet  Request  Packet  keeps  the  following 
information  in  its  eight  byte  structure: 

command  (i.e.  OOH  means  eventcount) 

type_name  (i.e.  8  bit  eventcount  id) 
name_value  (i.e.  16  bit  eventcount  value) 
remote_addr  (i.e.  16  bit  addr  of  external  cluster) 

System  event counts  ERB_WRITE  and  ERB_READ  play  the 
functional  roles  of  <dataname>_IN  and  <dataname>_OUT 
respectively  for  this  system  shared  data  queue. 

We  realize  that  ERPs  in  the  ERB  are  in  partial 
order.  The  order  of  packets  for  different  event counts 
<dataname>_IN  or  <dataname>_OUT  is  of  minor  importance.  More 


10000 

10078 

10666 

10C58 


17FFF 


Transmit.  Data  Block 


Receive  Data  Block 


User  Shared  Data 
Block 


Shared  Memory 


command 
type_name 
name_value 
remote  address 


Figure  3.1  The  Ethernet  Request  Block 


important  to  notice  is  that  the  logic  of  eventcounts,  if 
used  correctly,  ensures 

a)  that  a  packet  with  an  eventcount  <dataname>_OUT  always 
comes  after  a  packet  with  the  respective  eventcount 
<  da t  aname  >_IN ,  and 

b)  that  all  packets  with  eventcounts  <dataname>_IN  for  a 
specific  data  queue  are  in  total  order,  which  is  also  true 
for  all  packets  with  eventcounts  <dat aname >_OUT  for  a 
specific  data  queue. 

2.  User  Shared  Data  Block 

As  mentioned  above,  user  shared  data  queues  can  be 
of  any  length  and  the  data  items  can  be  of  any  structure, 
but  every  data  item  has  a  specific  structure  that  is 
replicated  in  every  slot  of  its  data  queue. 

Due  to  the  information  contained  in  the  eventcount 
value,  a  specific  slot  in  a  data  queue  has  to  be  written 
before  the  eventcount  is  advanced  and  also  the  eventcount 
has  to  have  been  advanced  before  the  next  slot  is  written 
to.  The  application  programmer  has  to  be  aware  of  this 
logical  sequence  when  using  eventcounts.  The  system  then 
ensures  that  always  the  next  higher  slot  in  the  queue  is 
written  to,  and  this  only  if  this  slot  is  available  for 
overwrite . 

This  scheme  also  ensures  that  the  data  items  in  a 
respective  queue  are  totally  ordered.  Furthermore,  it  is 
ensured  that  respective  Ethernet  Request  Packets  that  keep 
value  information  of  an  eventcount  related  to  this  data  item 
are  in  the  same  order  as  the  data  item  iterations  in  the 
data  queue.  This  is  also  true  if  an  eventcount  relates  to 
multiple  data. 

These  facts  about  the  relation  between  eventcounts, 
Ethernet  Request  Packets,  and  user  shared  data  is  the  basis 
for  the  logic  of  the  implementation  of  the  drivers  data 
transmission  and  data  reception  tasks. 
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Figure  3.2  User  Shared  Data  Queues 
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E.  INTRACLUSTER  DATA  FLOW 


As  mentioned  earlier,  we  assume  to  have  the  classical 
producer- consumer  situation  for  all  user  shared  data  in  the 
system.  Data  items  are  kept  in  circular  data  queues  that 
seirve  as  buffers  between  producers  and  consumers.  Due  to 
this  assumption,  all  user  shared  data  are  related  to  some 
eventcount,  which  replaces  the  semaphore  used  in  the 
classical  example.  Refer  to  Figure  3.3  for  the  following 
discussion. 

A  user  process  resides  in  the  user  area  of  local  RAM  on 
some  SBC.  The  process  becomes  active  when  the  scheduler 
chooses  it  as  the  next  process  to  run  after  it  was  ready. 
Before  a  producer  process  can  place  the  produced  data  item 
into  the  queue,  a  slot  must  be  available.  Slot  availability 
can  be  checked  by  comparing  the  <dataname>_IN  and  the 
<dataname>_OUT  eventcount  values  of  the  respective  data 
queue . 

A  consumer  process  becomes  ready  only  when  the  value  of 
the  respective  <dataname>_IN  eventcount  has  reached  the 
awaited  threshold,  indicating  that  there  is  a  new  iteration 
of  the  data  item  available  in  the  data  queue. 

A  process  which  consumes  data  and  produces  new  data  as 
well  obeys  the  same  rules.  It  is  of  utmost  importance  that 
the  application  programmers  use  eventcounts  and  the  AWAIT 
and  ADVANCE  primitives  correctly. 

A  producer  process  when  running  produces  shared  data 
items,  puts  these  items  into  user  shared  memory,  if  there  is 
space  in  the  queue,  and  then  calls  the  system  primitive 
ADVANCE  (EVC).  This  system  process  then  increments  the  value 
of  the  respective  eventcount  and  checks  if  this  eventcount 
is  distributed  and  therefore  a  cluster  external  copy  needs 
to  be  updated.  If  so,  it  calls  another  system  primitive, 
SySTEM$IO,  whic'  in  turn  gets  a  ticket  from  the 
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ERB_WRITE_REQUEST  sequencer  and  puts  an  Ethernet  Request 
Packet  into  the  Ethernet  Request  Block  when  its  ticket 
number  becomes  the  lowest  in  the  waiting  line. 

If  no  remote  copy  is  needed,  then  no  Ethernet  Request 
Packet  is  produced,  because  all  consumers  reside  in  the  same 
cluster  as  the  producer,  and  the  cluster  internal 
synchronization  can  take  place,  as  all  needed  data  (i.e. 
eventcount  value  and  shared  data,  if  any)  is  present  at  the 
cluster.  A  waiting  consumer  process  becomes  ready  and  when 
activated  consumes  the  shared  data  item  from  Shared  Memory. 


IV.  INTERCLUSTER  DATA  SHARING  IN  RTC 


A.  INTERCLUSTER  CONNECTION 
1.  The  Ethernet 

As  mentioned  in  the  system  oveirview  in  Chapter  I, 
all  clusters  in  RTC*  are  connected  via  an  Ethernet  Local 
Area  Network.  A  detailed  specification  of  the  Ethernet  is 
given  by  Xerox  Corporation  [Ref.  9].  The  Ethernet  provides 
the  lowest  two  levels  in  the  International  Standards 
Organization’s  Open  System  Interconnection  (ISO  OSI) 
reference  model,  i.e.  the  Physical  Layer  and  the  Data  Link 
Layer.  Higher  levels  are  collectively  seen  by  the  Ethernet 
as  the  Client  Layer.  The  RTC*'s  driver  provides  the 
system's  Client  Layer  and  the  home  board  of  the  driver,  SBC 
1,  serves  as  a  host  in  the  Ethernet's  communication  subnet. 
The  physical  connection  of  a  cluster  to  the  Ethernet's 
coaxial  cable  is  provided  via  the  ECCB  NI3010,  the  interface 
between  the  MULTIBUS  and  the  transceiver  which  actually  is 
the  tap  clamped  on  the  coaxial  cable. 

While  the  interface  board  provides  the  hardware 
connection  between  the  highest  level  system  bus  (Ethernet) 
and  the  cluster  bus  (MULTIBUS),  the  ECCB  software  and  the 
driver  are  responsible  for  correct  exchange  of  messages 
transmitted  or  received  by  any  cluster  in  RTC*. 

As  is  true  for  all  SBCs ,  also  communication  with  the 
ECCB  NI3010  has  to  be  done  via  board  external  buffers.  In 
contrast  to  inter-SBC  communication,  which  is  synchronized 
by  eventcounts,  intercommunication  between  SBC  1,  the 
driver's  home  board,  and  the  ECCB  is  synchronized  using 
interrupts  (e.g.  Transmit_DMA_Done  or  Receive_DMA_Done) . 

An  in  depth  description  of  the  hardware  NI3010  is 
given  by  InterLAN  Corporation  [Ref.  10].  The  software 
driver  was  developed  by  David  Brewer.  Brewer's  thesis 
provided  the  basic  scheme  for  intercluster  exchange  of 


eventcount  values.  The  contribution  of  this  thesis  is  to 
enhance  the  basic  scheme  for  a  general  data  exchange  in  the 
system  by  modifying  the  driver  software  and  exploiting  the 
logical  interrelation  between  event counts  and  shared  data. 

2.  The  Ethernet  Packet 

Figure  4.1  shows  the  frame  format  of  an  Ethernet 
packet.  This  is  a  given  structure  produced  by  the  ECCB. 
Information  to  be  put  into  four  of  the  six  fields  have  to  be 
provided  by  the  client.  Preamble  and  Frame  Check  Sequence 
are  added  by  the  ECCB  for  receiver  synchronization  and  error 
checking  respectively. 

For  a  destination  address,  any  six  byte  combination 
except  all  zeroes  can  be  used,  which  is  also  true  for  the 
source  address.  The  arrows  on  the  right  hand  side  and  the 
bottom  of  Figure  4.1  indicate  the  serial  transmission 
sequence  of  the  bytes  and  bits.  The  very  first  bit 
transmitted  in  the  destination  field  indicates  whether  the 
destination  address  is  a  multicast  or  a  physical  address.  If 
this  bit  is  1,  making  the  first  byte  of  the  destination  an 
odd  number,  then  this  address  is  a  multicast  address  (group 
address  of  any  number  of  clusters).  A  special  multicast 
address,  all  ones,  is  reserved  as  the  so-called  broadcast 
address,  which  addresses  all  participants  in  the  network. 

If  the  first  bit  is  0  then  the  destination  is  a 
physical  address.  Physical  addresses  are  fixed  addresses  of 
ECCBs.  Xerox  Corporation  takes  care  that  physical  addresses 
are  unique,  i.e.  every  physical  address  is  used  only  once  in 
any  ECCB  worldwide. 

Due  to  the  just  described  restrictions,  there  are 
actually  2**47  different  combinations  available  to  be  chosen 
as  non-physical,  non-broadcast  destination  addresses.  For 
the  present  implementation  of  RTC*  it  was  decided  that  two 
bytes  are  more  than  adequate,  because  the  maximum  number  of 
stations  for  an  Ethernet  Local  Area  Network  is  restricted  to 
1024  by  the  Ethernet  specification.  Therefore  the  first 


four  bytes  of  the  destination  are  kept  fixed  03H,  OOH,  OOH, 
OOH  providing  the  multicast  indication  by  an  odd  first  byte. 

For  the  the  source  address,  the  ECCB  allows  two 
possible  ways.  Either  this  address  is  not  provided  by  the 
client,  in  this  case  the  ECCB  automatically  inserts  its 
physical  address,  or  the  client  fills  in  a  source  address. 
This  second  way  speeds  up  the  transmission  process  and  was 
therefore  chosen  for  RTC*.  The  first  four  bytes  are  kept 
fixed  03H,  OOH,  OOH,  OOH  as  in  the  destination  field.  Byte 
five  and  six  conta:.n  the  cluster's  address.  This  is  not  the 
ECCB's  physical  address  as  mentioned  by  David  Brewer,  but 
rather  a  software  address  of  the  transmitting  cluster. 

The  two  bytes  of  the  type  field  are  reserved  for 
use  by  higher  levels.  Clients  can  use  this  field  in  order  to 
exchange  information  about  a  specific  format  used  in  the 
data  field.  The  present  implementation  of  RTC*  will  not  use 
the  type  field  and  therefore  sets  it  to  OOH,  OOH. 

The  data  field  provides  space  for  up  to  1500  bytes. 
It  is  required  that  the  minimum  length  of  the  data  field  be 
46  bytes  in  order  to  generate  the  minimum  total  length  of  a 
sufficiently  long  message.  This  minimum  message  size 
requirement  guarantees  that  in  any  Ethernet  collisions  are 
detected  by  the  sending  stations,  even  if  source  and 
destination  stations  are  maximum  distance  (2.5  km)  apart, 
and  the  net  performs  at  worst  case  propagation  speed 
tolerated  by  the  Ethernet  specification.  Collision  detection 
by  the  sending  station  is  important  for  correct  backoff  and 
retry  in  order  not  to  loose  messages  in  the  network.  The 
ECCB  takes  care  of  this  minimum  length  requirement  as  will 
be  seen  later.  Also  the  sending  ECCB  attaches  a  four  byte 
frame  check  sequence  at  the  end  of  every  Ethernet  packet  in 
order  to  provide  a  basis  for  error  checking  to  the  receiving 


B.  DRIVER  -  ECCB  MESSAGE  HANDOVER 

By  a  chosen  wiring  option,  it  is  not  possible  to  access 
(write  or  read)  onboard  memory  of  an  SBC  or  the  ECCB  from 
outside  the  board.  Therefore  a  buffer  for  message  handover 
is  needed  for  outgoing  messages  as  well  as  for  incoming 
ones.  These  buffers  are  set  up  in  Shared  Memory  as  systems 
shared  data  Transmit  Data  Block  and  Receive  Data  Block.  In 
contrast  to  other  shared  data  (e.g.  Ethernet  Request  Block 
or  user  shared  data),  the  Transmit  Data  Block  and  the 
Receive  Data  Block  are  single  slot  queues  that  meet  the 
structure  requirements  given  by  the  ECCB  specification 
described  in  the  Ethernet  Communication  Controller  User 
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Transmit  Data  Block 


The  Transmit  Data  block  is  a  structure  of  1514  bytes 
that  contains  all  information  required  to  be  submitted  by 
the  client  in  order  to  enable  the  ECCB  to  build  the  Ethernet 
packet  described  above.  Figure  4.2  shows  this  structure.  The 
destination  and  source  fields  are  filled  with  the  preset 
address  parts  as  well  as  the  dynamically  changing  two  high 
bytes  of  the  destination.  The  type  field  keeps  the  values 
OOH,  OOH,  and  the  actual  message  content  is  kept  in  the 
lower  part  of  the  1500  bytes  data  field. 

2 .  Receive  Data  Block 

The  Receive  Data  Block,  see  Figure  4.2,  is  similar 
to  the  Transmit  Data  Block  and  carries  all  information 
contained  in  an  incoming  message,  i.e.  destination,  source, 
type  and  data  field.  In  addition,  the  receiving  ECCB  hands 
over  status  information  related  to  the  message,  that  can  be 
used  by  the  client  in  order  to  determine  the  length  and  the 
error  status  of  the  received  packet.  These  additional  items 
of  information  are  kept  in  the  first  four  bytes  (1  byte 
frame  status,  1  null  byte,  2  bytes  frame  length)  and  the 
last  four  bytes  (frame  check  sequence)  of  the  Receive  Data 
Block,  making  the  Receive  Data  Block  1522  bytes  long. 
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The  present  implementation  of  RTC*'*  ignores  the 
frame  check  sequence  and  concerns  itself  only  with  the  data 
field. 

Even  though  the  length  of  the  data  field  in  the 
Ethernet  packet  is  determined  by  the  length  of  the  actual 
message,  both,  the  Transmit  Data  Block  and  the  Receive  Data 
Block  provide  space  for  maximum  length  messages  in  order  to 
be  prepared  for  any  legal  message  size. 

C.  MESSAGE  TRANSMISSION  AND  RECEPTION 

The  main  task  of  the  driver  on  SBC  1  is  to  build  a 
message  that  is  to  be  transmitted  over  the  Ethernet,  and  to 
process  a  message  that  was  received.  For  transmission,  the 
message  has  to  be  built  in  the  Transmit  Data  Block  in  Shared 
Memory  first ,  and  then  the  ECCB  is  to  be  triggered  for 
transmission.  For  reception,  after  the  ECCB  signaled  that 
it  has  put  a  message  into  the  Receive  Data  Block  in  Shared 
Memory,  the  correct  data  queues  in  Shared  Memory  have  to  be 
found  and  the  data  items  have  to  be  put  into  the  correct 
slots  in  their  respective  data  queues. 

In  order  to  be  able  to  do  this  correctly,  every  driver 
maintains  a  table  in  its  local  RAM  which  contains  all  the 
information  needed  about  the  relationship  between 
eventcounts  and  shared  data  items. 


1 .  The  Relation  Table 

We  assume  that  every  user  shared  data  item  used  in 
the  system  is  related  to  some  eventcount.  The  driver 
exploits  <dataname>_IN  eventcount,  because  this  is  the 
trigger  for  shared  data  transmission  when  put  into  an 
Ethernet  Request  Packet  by  the  SYSTEM$IO  process. 

Only  if  a  <dataname>_IN  eventcount  was  advanced,  was 
there  a  new  data  item  put  into  the  respective  data  queue.  An 
eventcount  can  also  serve  as  a  <dataname>_IN  indicator  for 
multiple  data  items  that  are  updated  at  the  same  time.  The 
important  property  is  that  for  every  shared  data  item  there 
exist  one  <dataname>  IN  eventcount.  which  is  advanced  after 


the  data  item  is  available  in  its  corresponding  data  queue 
in  Shared  Memory.  Only  if  an  eventcount  is  distributed  over 
the  system,  and  therefore  a  cluster  external  copy  is  needed, 
is  there  an  Ethernet  Request  Packet  produced- and  put  into 
the  Ethernet  Request  Block.  Every  data  item  is  distributed 
over  the  same  clusters  as  the  eventcount  to  which  it  is 
related.  A  <dataname>_OUT  eventcount  only  informs  everybody 
in  the  system  that  a  slot  in  the  respective  data  queues 
becomes  available  for  overwriting  (an  important  item  of 
information  for  producer  processes),  and  so  these 
eventcounts,  if  distributed,  will  be  transmitted  alone,  with 
no  user  shared  data  in  the  same  Ethernet  message. 

This  logical  interrelation  between  eventcounts  and 
user  shared  data  is  kept  in  the  relation  table  shown  in 
Figure  4.3,  which  is  a  structure  of  100  entries  (the  present 
implementation  of  RTC*  allows  for  100  eventcounts  per 
cluster),  which  holds  the  eventcount_id  and  the  number  of 
related  data  items  on  level  two,  and  information  about  up  to 
10  data  items  for  every  eventcount  on  level  three.  Besides 
the  knowledge  about  how  many  data  items  belong  to  some 
eventcount,  the  driver  needs  to  know,  where  to  find  a  data 
item,  what  is  the  items  structure  size,  what  is  the  data 
queue  length,  what  is  the  next  slot  to  be  sent,  and  what  is 
the  next  slot  into  which  to  put  a  received  item. 

The  relation  table  is  built  by  the  driver  during 
system  initialization  by  the  procedure  make_table,  see 
Appendix  A.  This  procedure  reads  the  file  relation.dat, 
which  has  to  be  present  on  the  disk  that  keeps  the  cluster's 
software . 

The  driver  (see  Appendix  D)  is  a  general  system 
process  that  is  identical  at  every  cluster.  The  relation 
table  is  cluster  specific  and  keeps  cluster  specific 
information  only.  The  relation.dat  file  has  to  be  set  up  by 
the  lead  programmer,  who  decides  what  application  program  is 
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Figure  A. 3  The  Relation  Table. 

to  be  run  at  what  cluster,  and  therefore  knows  what 
eventcounts  and  user  shared  data  are  needed  at  a  cluster. 

The  relation.dat  file  basically  is  a  table 
consisting  of  five  columns  as  shown  in  Table  I.  It  keeps 
eventcount  identification,  number  of  data  related  to  this 
eventcount,  and  for  every  data  item  the  address  of  the  first 
byte  in  its  data  queue,  the  length  of  the  data  queue  (fit  of 
slots),  and  the  length  of  the  data  item  structure  (fit  of 
bytes).  The  last  line  in  the  relation.dat  file  serves  as  a 
sentinel  consisting  of  zeroes  in  all  five  columns.  The 
procedure  make_table  expects  the  formatted  indata  to  be  in 
columns  5,  15,  25,  35,  45  respectively.  This  information  is 
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TABLE  I 

FILE  RELATION.DAT 
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read  into  the  relation  table  entries  evc_id,  numdat , 
pointer,  qlen,  and  bytes  respectively.  Next_in  and  next_out 
are  initially  0  and  therefore  do  not  have  to  be  read  in. 

The  information  kept  in  the  relation  table  suffices 
for  the  driver  to  do  its  job.  The  driver  does  not  need  to 
know  anything  about  the  logical  structures  or  names  of  data 
items.  It  treats  a  data  item  as  a  sequence  of  bytes,  and  is 
only  interested  in  finding  the  correct  sequence  of  bytes  for 
transmission,  or  the  correct  place  in  Shared  Memory  to  put 
the  bytes  after  reception.  Procedures  make_message  and 
process_packet  take  care  of  this. 

2 .  Data  Format 

A  decision  that  had  to  be  made  was  in  what  manner 
the  data  field  of  an  Ethernet  Packet  should  be  used  in  order 
to  exchange  data  in  RTC*.  The  question  was  discussed  whether 
to  use  different  fixed  formats  for  different  situations  and 
using  the  type  field  for  identification  of  the  format  used 
in  the  data  field.  After  recognizing  the  logical 
interrelationship  between  eventcount  and  shared  data,  that 
carries  the  possibility  of  uniquely  identifying  a  group  of 
shared  data  by  its  common  eventcount,  it  was  decided  to  keep 


the  data  format  as  flexible  as  possible. 

The  first  four  bytes  of  the  data  field  will  always 
keep  the  eventcount  information  followed  by  as  many  data 
items  as  are  related  to  this  eventcount.  The  maximum  length 
of  these  data  items  together  is  restricted  to  1496  bytes  in 
order  to  respect  the  1500  byte  limit  of  the  data  field  when 
the  4  byte  eventcount  information  is  included.  This  seems 
to  be  more  than  adequate  for  the  purpose  of  RTC*,  and  still 
leaves  the  possibility  to  transmit  all  data  items  as  long  as 
a  single  item  is  not  longer  than  1496  bytes,  by  logically 
grouping  data  items  under  eventcounts  respecting  this 
restriction. 

The  eventcount  is  the  identifying  part,  therefore 
only  one  eventcount  is  transmitted  in  any  Ethernet  packet. 

3 .  Message  Transmission 

Message  transmission  is  triggered  by  an  Ethernet  Request 
Packet  (ERP)  available  in  the  Ethernet  Request  Block  (ERB); 
more  precisely,  by  an  advanced  eventcount  ERB_WRITE 
indicating  that  there  is  an  ERP  in  the  ERB  which  has  not 
been  processed  yet.  The  driver  with  its  preference  for 
outbound  messages  will  start  a  transmit  job  as  soon  as 
possible.  In  the  initialization  part,  the  driver  already  has 
preset  the  first  four  bytes  of  the  destination  field  and  all 
six  bytes  of  the  source  field.  Refer  to  Figure  4.4  for  the 
following  discussion. 

Bytes  five  and  six  of  the  ERP  are  copied  into  the 
two  high  bytes  of  the  destination  field  of  the  Transmit  Data 
Block,  making  the  first  14  bytes  of  the  Transmit  Data  Block 
complete . 

Next  a  four  byte  overlay  is  put  over  the  ERP,  using 
a  based  variable  [Ref.  11],  after  which  the  procedure 
make_message  (see  Appendix  B)  is  called. 

This  procedure  first  checks  if  the  ERP  contains  an 
eventcount  (in  the  present  implementation  only  eventcount 
related  ERPs  are  processed).  If  byte  one  of  the  ERP 


Figure  4.4  Message  Transmission 


contains  OOH,  indicating  EVC_TyPE  then  the  first  four  bytes 
of  the  ERP  are  copied  over  into  the  first  four  bytes  of  the 
data  field  of  the  Transmit  Data  Block. 

Next  a  relation  table  look  up  is  done  under  the 
respective  eventcount_id  and  the  number  of  related  data 
items  is  found.  If  the  event count_id  is  not  in  the  table, 
then  there  are  no  related  data  and  the  message  is  done, 
otherwise  the  first  related  data  item  is  found,  an  overlay 
(1500  bytes  in  the  present  implementation)  is  aligned  with 
the  data  queue,  using  the  address  information  (pointer)  of 
the  data  item.  Now  the  slot  number  (next_out)  and  item 
size(bytes)  are  combined  to  an  offset  in  order  to  find  the 
first  byte  to  be  copied  over  into  the  Transmit  Data  Block  to 
follow  the  eventcount  information  in  the  data  field.  The 
data  item  size  (bytes)  contains  the  number  of  bytes  to  be 
copied  over. 

The  next_out  of  this  data  item  in  the  relation  table 
is  updated  to  the  next  slot  number,  and  the  loop  starts 
again  for  the  next  data  item  related  to  this  eventcount. 
Meanwhile  also  the  total  bytecount  for  bytes  put  into  the 
data  field  of  the  Transmit  Data  Block  is  carried  on.  After 
all  the  related  data  has  been  copied  over  into  the  Transmit 
Data  Block,  this  bytecount  information  is  added  to  14  (6 
bytes  destination,  6  bytes  source,  2  bytes  type)  and  the 
resulting  bytecount  is  used  as  a  parameter  in  the  procedure 
transmit_packet ,  which  signals  the  ECCB  that  a  message  is 
ready  to  go  and  should  be  sent. 

Just  before  calling  procedure  transmit_packet ,  the 
driver  calls  ADVANCE  (ERB_READ) ,  which  makes  the  just 
processed  ERP  slot  available  for  reuse. 

The  ECCB  copies  the  number  of  bytes  signaled 
(minimum  60)  into  its  transmit  queue  and  puts  the  message 
out  over  the  Ethernet.  If  necessary  due  to  collisions,  the 
transmission  is  repeated  and  only  after  the  message  was 
successfully  sent  does  the  transmitter  become  ready  for  the 
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next  transmission,  which  is  prepared  by  the  driver  in  the 
above  described  fashion. 

4 .  Message  Reception 

Message  reception  is  triggered  by  an  ECCB  interr  pt 
signaling  that  there  is  a  received  message  available  in  the 
ECCB's  receive  queue.  Refer  to  Figure  4.5.  The  driver  then 
initializes  a  DMA  and  the  ECCB  puts  the  message  into  the 
Receive  Data  Block  in  Shared  Memory.  After  the  message  is  in 
the  Receive  Data  Block,  the  procedure  process_packet  (see 
Appendix  C),  is  called.  This  procedure  works  similarly  to 
the  procedure  make_message. 

Instead  of  getting  the  needed  information  from  an 
ERP,  procedure  process_packet  has  to  look  up  the  first  bytes 
in  the  data  field  of  the  received  message.  This 
implementation  of  RTC*  neither  uses  the  frame  status  and 
frame  length  information,  nor  the  frame  check  sequence. 

First  the  procedure  process_packet  looks  up  byte  one 
of  the  data  field  in  order  to  check  if  the  just  received 
message  contains  eventcount  information.  If  so,  it  finds  out 
if  the  value  of  the  just  received  eventcount  is  higher  than 
the  local  value  of  the  respective  eventcount,  because  the 
message  is  of  interest  for  this  cluster  only  if  the  remote 
eventcount  value  is  more  advanced  than  the  local  one. 

If  the  remote  value  is  higher,  a  relation  table  look 
up  is  made  under  the  event count_id  found  in  byte  two  of  the 
data  field. 

If  there  is  no  entry  in  the  relation  table  for  this 
eventcount,  then  no  related  data  exists  and  the  only  thing 
to  do  is  to  update  the  local  eventcount  value. 

If  an  entry  exists,  then  the  address  (pointer)  of 
the  first  related  data  item  is  found,  an  overlay  is  aligned 
with  the  respective  data  queue,  and  the  slot  number 
(next_in)  and  the  item  size  (bytes)  are  combined  to  an 
offset  in  order  to  find  the  first  byte  in  the  data  queue 
that  is  to  he  changed.  Then  the  number  of  bytes  found  in  the 
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Figure  4.5  Message  Reception 


item  size  information  is  copied  over  into  the  data  queue, 
starting  with  byte  five  of  the  Receive  Data  Block's  data 
field  (i.e.  the  first  byte  of  the  first  related  data  item 
received). 

During  this  operation  also  the  bytecount  is  updated 
in  order  to  find  the  starting  byte  for  the  next  related  data 
item. 

Similar  to  the  procedure  make_message ,  the  procedure 
process_packet  updates  the  next_in  information  to  the  next 
slot  number  in  order  to  be  ready  for  the  next  incoming 
message  bringing  an  update  for  this  data  item  if  any. 

After  the  first  shared  data  item  is  copied  into  its 
correct  slot  in  Shared  Memory,  the  next  related  item  is 
copied  into  its  respective  queue.  After  all  received  related 
data  items  of  the  received  eventcount  are  updated,  the 
eventcount  is  advanced  to  its  new  value,  signaling  the 
shared  data  status  to  respective  consumers  at  this  cluster. 
The  procedure  process_packet  takes  care  of  advancing  the 
eventcount  only  after  all  related  shared  data  items  are 
updated,  guaranteeing  the  consistency  of  eventcount  values 
and  data  items. 

D.  DATA  SHARING 

It  is  obvious  that  data  sharing  using  buffers  in  Shared 
Memory  can  only  be  achieved  when  producers  and  consumers 
agree  upon,  where  to  put  and  to  find  the  respective  data 
items.  Also,  this  only  works,  if  producer  and  consumer  deal 
with  the  same  item  structure. 

In  a  system  like  RTC*,  where  probably  many  applications 
programmers  write  different  system  modules,  these 
programmers  have  to  agree  upon  the  shared  data  names  and  the 
structures  and  queue  lengths  (at  least  for  intracluster 
sharing) . 

Even  though  it  would  suffice  to  only  declare  those 
shared  data  items  that  are  actually  used  in  some  process, 
the  policy  followed  in  the  demonstration  program  was  to 


include  a  common  declaration  file  in  every  module  in  order 
to  ensure  that  sharing  modules  really  work  with  the  same 
data  item.  Following  this  example  in  a  real  program  makes  it 
easier  to  maintain  all  shared  data  declarations,  probably 
done  by  the  lead  programmer. 

Applications  programmers  include  the  shared  data  file 
in  their  programs  and  only  have  to  be  concerned  about  the 


correct  use  of  those  items  actually  used  in  their  programs. 
Table  II  shows  the  file  share. del  for  the  demonstration 
program. 


TABLE  II 
FILE  SHARE. DCL 


DECLARE 


(de_ptr , tr_ptr ,mo_ptr )  pointer, 


1  delta(0:19)  based(de  ptr), 
2  dx  fixed  bin  T?), 

2  dy  fixed  bin  (7), 

2  dz  fixed  bin  (7 ) , 


1  track(0:<+9)  basedftr  ptr), 
2  X  fixed  bin  (15'  ~ 

2  y  fixed  bin  (15 

2  z  fixed  bin  (15 


1  missile  order(0:49)  based(mo  ptr), 
2  launcher  fixed  bin  (7), 

2  azimuth  float  binary, 

2  elevation  float  binary; 


This  file  ensures  unique  declarations  for  all  user  shared 
data  in  the  whole  system. 

Every  user  shared  data  item  is  declared  as  a  queue  that 
is  based  on  a  respective  pointer.  Using  based  variables 
provides  the  possibility  that  in  spite  of  total  user  shared 
data  declaration,  only  for  those  items  that  are  to  be 
resident  in  some  cluster’s  Shared  Memory  physical  memory 
space  is  assigned.  This  leads  to  efficient  use  of  memory 


space.  As  mentioned  before,  contiguous  storage  of  data 
queues  enhances  the  efficiency  even  more. 

This  requires  thoughtful  assignment  of  addresses  to  the 
different  data  queues  in  the  system.  As  for  the  relation.dat 
file  and  share. del  file,  the  custodian  for  the  assignment  of 
pointers  also  should  be  the  lead  programmer.  Applications 
programmers  do  not  have  to  worry  about  this  because  they 
refer  to  a  data  item  by  dataname.  Pointer  assignments  are 
kept  in  the  file  pointer. ass,  which  is  cluster  specific;  the 
share. del  file  is  the  same  for  every  cluster  in  the  system. 
Table  III  shows  the  two  pointer. ass  files  used  in  the 
demonstration  program. 


TABLE  III 
FILE  POINTER. ASS 


this  file  keeps  the  pointer  assignments 
for  shared  variables  used  at  cluster  1 


unspec(tr_ptr)= ’ 8c58 ’b4; 
unspec(mo_ptr)=  8d84  b4; 


*/ 


/* 


this  file  keeps  the  pointer  assignments 
for  shared  variables  used  at  cluster  2 

^7 


In  order  for  processes  to  be  able  to  really  share  di,ta 
in  Shared  Memory,  it  is  important  that  they  find  shared  data 
under  the  same  physical  address.  Under  INTEL'S  policy  that 
calculates  a  20  bit  physical  address  from  a  segment  and  an 
offset,  this  implies  that  user  shared  data  has  to  be  found 
in  the  same  segment,  the  pointer  or  logical  address  then  is 
the  offset  in  this  segment. 


In  RTC^  this  is  realized  in  using  800H  as  a  data  segment 
register  value  and  using  sixteen  bit  pointers  for  shared 
data  starting  at  8000H.  The  lowest  Shared  Memory  address 
therefore  is  800H*10H+8000H,  which  is  equal  to  8000H+8000H, 
or  lOOOOH.  The  lowest  byte  of  the  Ethernet  Request  Block 
resides  at  the  above  address. 

The  segment  used  by  a  process  is  defined  in  procedure 
create_proc.  It  is  important  that  the  parameters  4,  7,  and 
8,  i.e.  stack  segment  (SS),  data  segment  (DS),  and  extra 
segment  (ES)  in  the  create_proc  call  are  set  to  800H  when 
creating  a  process.  As  mentioned  by  Brewer  ,when  he 
describes  user  process  creation  [Ref.  1:  p.  49],  some 
PL/I-86  routines  assume  identical  contents  in  the  SS,  DS , 
and  ES  registers. 


V.  CONCLUSION 


The  goals  of  this  thesis  were  achieved.  The  MCORTEX  real 
time  executive  is  extended  to  handle  multicluster  general 
inter-process  data  communication.  An  appropriate  model  for 
intercluster  shared  memory  is  implemented  by  partial 
replication  of  intracluster  shared  memory.  Only  PL/I-86 
modules  were  modified  or  newly  added. 

The  message  exchange  scheme  is  kept  as  flexible  as 
possible,  with  the  only  restriction  that  the  four  bytes  of 
eventcount  information  have  to  be  put  into  the  first  four 
bytes  of  the  data  field  of  the  Transmit  Data  Block,  and  all 
related  data  items  have  to  follow  in  the  sequence  given  by 
the  relation  table.  The  driver  takes  care  of  this. 

Maximum  data  length  in  a  single  message  is  restricted  to 
1500  bytes  in  accordance  with  the  Ethernet  specification. 
This  size  seems  more  than  adequate  for  the  purpose  of  RTC*. 
If  longer  messages  are  needed  in  the  system,  a  correct  data 
exchange  can  be  achieved  by  breaking  up  the  message  into 
smaller  ones  relating  these  to  specific  eventcounts. 

The  driver  takes  care  of  correct  message  assembling  and 
processing,  and  is  --  as  a  special  systems  module  with  a 
dedicated  board  --  completely  transparent  to  the 
applications  programmer  and  user.  The  lead  programmer  will 
have  to  decide  how  to  distribute  different  applications 
modules,  and  where  to  store  data  queues  in  Shared  Memory.  He 
or  she  will  have  to  maintain  the  relation.dat  file  and  the 
pointer. ass  file,  and  also  the  agreed  upon  user  shared  data 
in  the  share. del  file. 

In  the  current  implementation  of  RTC*  the  distributivity 
of  the  eventcounts  (and  with  these  the  distributivity  of 
data  items)  have  to  be  set  at  system  initialization.  This 
restricts  the  dynamic  reconfiguration  of  the  system  after 
initialization.  Future  implementations  should  try  to  resolve 


this  restriction.  A  possible  way  might  be  to  exploit  the 
general  broadcast  situation  of  an  Ethernet  environment.  As 
only  one  message  can  be  on  the  Ethernet  at  a  time,  and  as 
all  stations  on  the  net  have  to  listen  and  cannot  do 
anything  else  during  this  time,  this  situation  could  be 
exploited  in  the  following  manner. 

Use  the  eventcount_id  as  a  kind  of  multicast  address.  As 
there  is  only  one  event count  in  any  one  message  this  is  a 
unique  identification  of  what  information  is  carried  in  the 
message.  Every  cluster  "knows"  what  information  is  needed  at 
that  cluster.  If  the  eventcount_ids  of  related  data  items 
needed  at  some  cluster  are  put  into  the  group  address  table 
of  that  cluster's  ECCB,  then  every  Ethernet  packet  that 
carries  information  of  interest  for  this  cluster  will  be 
taken  in  and  processed. 

It  is  not  necessary  to  keep  the  remote  address  for  an 
eventcount  in  Common  Memory.  The  information  that  an 
eventcount  is  distributed  or  not  distributed,  meaning  a 
cluster  external  copy  is  needed  or  not  needed,  suffices. 
This  distributivity  information  can  be  initialized  for  the 
initial  system  constellation.  On  reconfiguration,  it  could 
then  be  automatically  and  dynamically  changed  without  having 
to  shut  down  and  reinitialize  the  whole  system. 

After  reconfiguration,  only  those  clusters  where  actual 
changes  were  made  broadcast  the  eventcount_ids  of  interest 
to  the  cluster.  Every  other  cluster  updates  its 
distributivK  information  for  those  eventcounts. 

There  was  not  enough  time  for  the  above  described 
implementation  in  this  thesis,  but  future  work  in  this 
direction  is  highly  recommended  in  order  to  make  the  total 
system  more  efficient,  more  robust,  more  survivable,  and 
more  flexible,  requirements  that  are  of  utmost  importance 
especially  for  military  applications. 


APPENDIX  A 
PROCEDURE  MAKE  TABLE 


Procedure  make_table  is  the  first  procedure  called  by 
the  driver.  It  sets  up  the  relation  table  in  local  RAM  of 
SBC  1  by  reading  the  information  from  the  file, 
relation.dat . 

The  relation  table  is  a  three  level  structure  that  keeps 
the  event count_id  (evc_id)  and  the  number  of  data  items 
(numdat)  related  to  this  eventcount  on  level  two  and  the 
data  queue  address  (point),  number  of  slots  in  dataqueue 
(qlen) ,  number  of  bytes  in  item  structure  (bytes),  next  slot 
to  be  sent  (next_out ) , and  next  slot  to  be  received  (next_in) 
on  level  three. 

There  are  maximum  100  level  one  entries  in  the  relation 
table,  because  the  maximum  number  of  eventcounts  at  any 
cluster  in  the  present  implementation  is  100.  For  every 
eventcount  a  maximum  of  10  related  data  items  are  possible. 
The  driver  looks  up  an  eventcount_id  and  finds  all 
information  necessary  to  either  combine  data  items  in  the 
Transmit  Data  Block  for  transmission,  or  put  received  data 
items  in  their  respective  Shared  Memory  slots. 

Procedure  make_table  expects  the  indata  evc_id  at  column 
5,  numdat  at  column  15,  point  at  column  25,  qlen  at  column 
35,  and  bytes  at  column  45  in  the  relation.dat  file. 
Next-out  and  next  in  are  initially  0  and  do  not  have  to  be 
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PROCEDURE  MAKE_TABLE  R.Hae^er,  Dec  1985 

4c4'4c _ >lcs!«4« 

4c«4(  This  procedure  reads  relation  values  from  file 

’S'**  RELATION.DAT  into  the  relation  table.  *** 

4t4c4c4s4c4c4c4c4c4c4cs;c4c4s4c4t4c4c4c4e4c4c4c4e4c4c4c4c4c4t4ss<c4c4:4c4c4c4:s{:4'4«4!4t4cslt4c4c4‘4c4c4c4c4cJi:4c4cs;c4'.>!c4c 


make_table;  procedure  I 

declare 

relation  file, 

(.1,i)  fixed  bin  (15), 
eof  bi t (e ) ; 

open  file  (relation)  stream  Input; 
i=0; 

eof='0'b4; 

do  while  ^eof='?''b4)  ; 
i=i+i; 

/*  read  data  from  relation. dat  file  */ 

^et  file  ^relation)  edit (rel_tab(l  )  .evc_ld  , 

rel_tab'i). numdat ) 

(column ' 5 ) ,b4( 2 ) , column ' 15  ) , f (2 ) )  ; 

do  J=1  to  ( rel_tab ( i ) .numdat ) ; 

/*  real  data  for  all  related  items  */ 

^et  file  ^relation)  edit 

(unspec  ( rel_tab  ( I )  .data  ( .i )  •'oolnt )  , 
rel_tab(  i )  .da  ta  ( .) )  .0  len  , 
rel~tab(  i).(lata(j). bytes) 

( column  (25  )  ,b4(4 ) , column  (35)  ,  f '  4  ) ,  column  ( 45  ) ,  f  ( 4  :■ )  i 
maxa  bytes=max (maxabytes , 

rel_tab(i).data(,l).bytes*rel_tab(l).lata(J).alen); 


end; 

/*  if  sentinel  Is  reached  */ 
if  rel_tab f l ) .evc_ld  =  'CC'bd  then 
do ; 

eof  =  'l  'b4; 

put  skin  lis t(  'longest  data  Queue  at  this  cluster:', 
maxabytes ,  '  bytes  '  ’> ; 

end; 

end; 

end  make  table; 
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APPENDIX  B 

PROCEDURE  MAKE_MESSAGE 

Procedure  make_message  is  called  by  the  driver  when 
there  is  an  Ethernet  Request  Packet  in  the  Ethernet  Request 
Block  that  has  not  been  processed  yet. 

It  checks  the  ERP  for  eventcount  type,  and  if  the  ERP 
contains  eventcount  information,  it  sets  up  the  data  field 
of  the  Transmit  Data  Block.  The  eventcount  information  is 
always  put  into  the  first  four  bytes  of  the  data  field, 
followed  by  all  data  items  related  to  this  eventcount  in  the 
sequence  given  by  the  order  of  these  data  items  in  the 
relation  table. 

Procedure  make_message  also  keeps  track  of  the  bytecount 
of  the  total  message,  an  information  needed  by  the  ECCB  for 
transmission. 
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•S'**  PROCErUHE  MAKE  MESSAGE  R.  Hae^er ,  Dec  1995 
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***  This  DTocedure  builds  the  Transnit  Data  Blocic  for 
4!##  a  message  to  be  transmitted  over  the  Ethernet. 

:{c  ](( lie  9^  igcjc  #  4t  xe  :ge  4c  4>  4C  4: 4c  3ic  4(  4>  KC  4C  4<  4c  4>  4c  4<  4c  etc  4C  4c  4(  4c  ite  «c  x:  4C  9it  4c  4c  4(  4: 4c  4c  4t  4=  4C  4c  9  Iji  4c  4C  4c  4c  ^c  4C  4c  4c  4: 4C  4: 4c 


make  message:  uroredure  ; 


declare 

lat_ptr  pointer, 

dat_vec t ( 1500 )  bit  (8)  based  (iat_?tr), 
( neTt_out , r , J )  fixed  bin  (7), 

^ off .start .last ,k)  fixed  bin  (15); 


/*  check  for  eve  */ 
if  erp_vect(l)=SVC_TYPE  then 
do ; 

by tecount=4; 
do  k=l  to  4; 

/*  out  eve  info  into  data  field  */ 
transnit_data_block.data{k)=erp_vect''k); 
end; 


/*  check  message 

put  skip  lis  t  (  ' :  : :  t ' .  traiismit_data_block  .data  (1 )  , 

transnit_data_blcck.data (2) . 
transmit_data_block.data(3), 
transmit  data  bl ock .data (4 ) . 


’); 

4c/ 


r=i; 

find  respective  relation  table  entry 
do  while  ( ( re l_tab ; r ) . evc_id  er?  vect(2))  & 
(  rel_tab(r  )  .evc_id  ”'=  '?0''b4)); 

r=r+l ; 
end; 


/*  if  eve  entry  */ 
if  rel_tat  (  r  ) .  ev  c_id  "'=  '00'b4  then 
do ; 

/4c  for  every  related  item  ’*'/ 
do  .1=1  to  rei_tab(r )  .numdat; 
start  =  tytecount  +  i;  find  where  to  put  ■••/ 

las  t=rel  tab  (  r  )  .data  ( ,i )  .by  tes ;  /'^  how  long  it  is  =*=/ 
bytecoun t=tyte count  +  last;  /*  keep  track  '*/ 
dat_ptr=rel_tab(  r)  .data  (.))  .point ;  /*align  datvect--'^/ 
riext_out  =  rPl_tab(r).data(.1).next_out; 

/*  compute  offset  of  item  in  data  oueue 
of  f  =  (  rel  _tab  (  r  )  .data  V  .1 )  .by  tes  *  next_out)  +  l; 
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/*  compute  next  slot  number  to  ^o  */ 
rel_tab( r ) .data( j ) .next_out=mod ( next_out  +  1, 

rel_tab(rT.data(j).alen); 

do  k=0  to  ( las  t-1 )  t 

/’*'  put  item's  bytes  into  data  field  ’«'/ 
transmit_iata_blocic.data(k-^start  )=da  t^vec t  ( k+of  f ) ; 
end ; 
end ; 
end; 

/’*'  compute  total  bytecount  for  message 
bytecount=bytecount  +  14; 
end; 

else  do;  /’**  if  not  eve 
end; 

end  make  message; 


Procedure  process_packet  is  called  by  the  driver  when 
there  is  a  newly  received  message  in  the  Receive  Data  Block. 

It  checks  the  received  data  for  eventcount  type,  and  if 
the  message  contains  eventcount  information,  it  checks  if 
the  received  remote  eventcount  value  is  higher  than  the 
local  value  of  the  respective  eventcount.  Only  if  the  remote 
value  is  higher  than  the  local  value,  it  processes  the 
received  message.  Using  the  eventcount_id  in  byte  two  of  the 
data  field,  a  relation  table  look  up  is  done  and  all 
received  data  items  are  put  into  their  correct  slots  in 
Shared  Memory. 

After  all  data  items  are  placed  correctly,  the  local 
copy  of  the  respective  eventcount  is  updated  by  calling 
ADVANCE (EVC) . 
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*’"*  PROCEDURE  ?RCCESS_PACKET  R.Haeeer.  Dec  1995 
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This  Drocedure  isroresses  received  messases. 

It  ta>es  the  data  from  the  Receive  Data  Block  and 
put  every  item  in  its  correct  slot  in  Shared  Memory. 

It  also  calls  for  an  update  of  the  evencourt  value. 


process_?acket :  procedure? 

D^’CLARE 

eve  id  bit  O  )  , 
local_evc_value  bit  (16), 

(dat_otr,p)  pointer, 
remote_evc_value  bit  (16)  based  (p), 
da t_vec t ( 15C ?* )  bit  ^8)  based  (dat_i5tr), 

( of f .start .last  ,k)  fixed  bin  (15). 

(next_in,  r  ..i )  fixed  bin  (7); 
put  skin  1 is t ( 'rece i vl ns ' ) ; 

/’*'  check  for  eve  */ 

if  receive_data_block.data{l)=evc_type  then 
do; 

p  =  addr  (receive_data_hlock.data '.3)  ) ; 
evcid=recei ve_data  block.data(2 ) ? 
local_evc_value  =  read(evcid); 
if  local_evc_value  <  remote_evc  value  then 
do ; 
r=i; 

/*  find  eve  entry  in  relation  table  */ 
do  while  ( (rel_tab(r )  .evc_id  evcid)  S. 

(  rel_tab  ( r  )  .evc_id  "'=  '00'b4)); 

r=r  +  l ; 
end ; 

If  rel_tat  ( r  )  .evc_id  ''=  '00 'b4  then 
do; 

bytPccunt=4;  /*  jump  over  eve  info  ’*'/ 

do  ,1  =  1  to  rel_ta  b ( r  )  .numdat ; 

start=by tecount  +  1 ;  compute  start  of  item  ***/ 

last=rel_tab ( r ) .data ( J ) .bytes ;  /*  and  lensth 
bytecount  =  bytecount  +  las t ;  /’^  and  item's  end  =*'/ 

next_in  =  rel_tabfr).data(J).r.ext  in* 

/*  comnute  offset  In  data  aueue  */ 
of f=( last*next_in)  +  i; 

/*  compute  next  slot  number  to  fill 
rel_tab(  r)  .data(.l)  .next_i  n=mod  (next_in+l. 

rel_tab  (  r )  .data  ( .1 )  .a  len ) ; 


dat_ptr=rel_tab( r ) .data (j ) .point f  /*  ali^n  datvecf"/ 

do  k:=0  to  f last-1); 

/*  put  item  bytes  into  data  oueue  */ 
lat_vec t (k+of f )=receive_data_bl ock .lata ( k+start ) * 
end;  ~ 
end; 
end; 

/'*  update  loral  eve  value 
do  while  (local_evc_value  <  remote_evc_value ) ; 

call  advance  (evcid); 

local_evc_value  =  add2bitl6(local_evc_value , '0001 'b4) ; 
end; 
end ; 

else  do;  /*  if  not  eve  */ 
end ; 

call  disable_cnu_iT’terrunts; 
end ; 

end  process_packet; 
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The  driver  is  the  software  link  between  a  cluster  and 
the  ECCB  that  hooks  up  a  cluster  onto  the  Ethernet.  It 
manages  all  cluster  external  message  exchange  (transmission 
and  reception) ,  and  sets  up  the  clusters  communication 
ability  in  the  first  place. 

The  driver  resides  in  the  user  area  of  SBC  1,  which  is 
dedicated  to  serve  as  the  cluster's  host.  The  executable 
file  names  are  C1PR0C.CMD  and  C2PR0C.CMD  for  the  two  cluster 
constellation  of  RTC*  in  the  AEGIS  lab  at  the  US  Naval 
Postgraduate  School. 

The  LINK86  Input  option  is  used  to  link  files  sysinitl, 
sysdev,  asmrout ,  and  gatemod  into  CIPROC.  Sysinit2,  sysdev, 
asmrout ,  and  gatemod  are  linked  into  C2PR0C. 

Cluster  specific  information  about  the  creation  and 
distribution  of  eventcounts  is  contributed  by  sysinitl  and 
sysinit2  respectively,  which  are  the  main  procedures  for  the 
linkage.  Additional  cluster  specific  information  is  read 
from  the  address.dat  file  and  the  relation.dat  file  during 
execution  at  runtime.  The  %included  files  sysdef.pli  and 
NISOlO.dcl  provide  system-wide  information. 


**=«'  CIPROC.INP  file 

««« _ Xt>ic>tc 

This  file  is  used  to  link  system  initialization,  *** 

s;;##  driver,  assembly  language  routines,  and  satemodule 
into  CIPROC.CM!),  the  executable  file  run  on  SBC  1  at 
*’«'*  cluster  1.  *** 
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clproc  = 

sysini  tl  [code  [a b  [439]  ]  ,data  [ab  [800] ,  m  [0]  ,ad  [82]  ]  ,maT)  [alll  ]  , 
sysdev , 
asmr out , 
gatemod 
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Cluster  1 

RELATION.DAT  file 

slcsjej^s 

♦xcsec  This  file 

keens  the 

data  used 

to  build 

the  relation 

XcsicXc 

table: 

Xc  sic  sic 

Xc  sic  sic 

XcXcXc 

xcxcxc  eve  id 

numdat 
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bytes 
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sic  Xc  see 

XcXtXc 
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col 

XCXCXC 
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45 
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sec  sic  sic  sjc  sec  sCe  s{c  sec  sec  s{c  sec  sic  sic  sec  sic  Xc  sec  sic  sje  sec  sec  see  sec  si;  sec  sic  sec  sec  sec  sec  sic  sfc  sec  sic  sic  sec  sic  sic  s(c  sec  sic  sit  s(c  sec  sic  sj:  sic  sic  sje  s(c  sic  sjc  sic  sje  sjc  sic  S{C  si:  sic  sec 


Cluster  1  ADDRESS.DAT  file 

sic  sic  sic. - - - - - - - - - - - - — - si:#  sit 


sicsic#  This  file  keeps  the  number  of  group  addresses, 
sicsicsic  cluster's  grouu  address  (es)  and  the  cluster's 
sfcsicsic  source  address. 

Sic  sic  sic  sic  sic  sic  si:  si:  Sic  se:  sic  s;:  sic  sec  sic  sic  s{c  Xc  sje  sic  sic  sec  sic  s;:  sic  sec  sic  sic  si;  sec  sic  sicsec  sic  sic  sec  sic  xc  sic  si:  sec  sec  sic  sic  sic  sic  sic  sic  sjt  sic  sic  sjc  sic  sec  sic  sic  sic  sic  sic  sic 

1. 

' 00000000' b, '00000001 'b, 

'00000000'b,  '00000001'b 


XssecXcsicsecsicsicsI:;le5etXcs!tslC5itXcsicXtXcXcsics;tsieXcXcsecsicsetXcXcXcsics!cXc5etXc5^sits|cs!:s!csiesicsecseeslcsecs)cXcs!e5ic3lcsicsI:XtsiC5!ts,:s!tXc 
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:t(#«i(K«i;^3;(4t:tc>tc#Xe>((>»cXc^ito^>;t:ecX(iecXc9!c:9C3tc«:tc«:(cKt:tc)(c«itc:(c:;c:t[:te3ic:^3;c»c:tc:tc:(c>i(«3!e3!c#j;c:tc^jtcjjc:4i:ec>!c« 


STSINITl.PII  file 

### - Jje^sls 

«««  This  is  the  system  Initialization  procedure  for 
cluster  1 . 


:)c  3}!  :}e  #  sj!  *  :!e  sjt  #  }|t  #  sjt  #  #  sjt « s)c  sjt  jj!  #  «  >!t  j[t  Xs  #  sit  ♦  :<t  # :!!  sS  sjt  !{t  #  #  #  >i!  #  s!«  s)t  #  sit  5(« !):  *  >:«  5)5  *  sS  sj!  *  « sis  :;<  # 

sysinitl:  proc  options  (main); 

"^include  'sysdef  .pli 
^replace 

EVC_TY?E  hy  "00 'b4; 

/'*  main  */ 

call  def ine_clus ter  ('0001"'b4)» 

/*  must  be  called  orior  to  creating  eve's  '-V 

USER  ^ttitsitsit/ 


ca 

11 

create_ 

eve 

(TRACK  IN); 

ca 

11 

create_ 

eve 

(TRACK  OUT); 

ca 

11 

create_ 

ev  c 

(MISSILE  ORDE 

?._IN); 

ca 

11 

create_ 

eve 

(MISSILE_ORDER_OUT) ; 

/sit 

3}!  sic 

SYSTEM 

sltsitsle  / 

ca 

11 

create_ 

eve 

(ER3  RE&D); 

call 

create” 

ev  c 

(ER5"WRITE) ; 

ca 

11 

create_ 

sea 

(ER3_WRITS_?.E 

QUEST) ; 

/sit 

di strib . 

mao 

called  after 

eventcoun' 

ts 

hav 

O 

been  crea 

ted 

/ 

ca 

11 

distribut ic 

n  map  (EVC  TYPE.  TRACK 

IN 

♦ 

0003'b4); 

/*  local 

and 

remote  copy 

of  TRACK  : 

[N 

needed 

ca 

11 

distribution  map  (EVC  TYPE.  MISSILE 

ORD 

ER_OUT  , 

'0003' 

b4) ; 

/’*'  local 

and 

remote  cooy 

of  MISSIL] 

S  ORDE 

R_CUT 

needed  =**/ 

/*  creat 

e  dr 

iver 

ca 

11 

create_ 

proc 

('fc"D4,  '80 

't4. 

'26a5'b4,  ' 

0S00'b4. 

'00 

5f  ' 

fc4, 

'0439'b4,  ' 

0P70 'b4. 

'  7C 

00  ' 

b4  '  ; 

ca 

11 

await  ( 

'fe' 

b4,  '01 'b4); 

end  sysiniti; 

« <t ;«c ]jc sje sje :(c )ic:(c sic :(c 3;t ](c :;c sic « 3{c :(c :tc 3(c ](c 9^ sac ««« );e sgcije sic ](c 3(1  stc 3CI 4t « Ki «  V s!c « ;;(« «i ^ 


:((#  :!t:tc  Jjc  s’;  3^  ^  :X  ^  3ic ’r  ^  lie  >S!  >i(  >!(:;<  lie  >!<  >|:  39^  99t  ^  ^ ^  ={<  >9^  >i< ’jc  >((  iCc  9t<  >)<>{<  3i<  4c  V  ^  ^  :!c 


***  C2PR0C.IMP  file 

«>tS3{! _ ^ejjesjt 


***  This  file  is  use!  to  link  system  initializatio  ,  *** 

>t'-#4t  driver,  assembly  language  routines,  and  gatemodule 
*^*  into  C2PR0C.CMD,  the  executable  file  run  on  SBC  1  at 
***  cluster  2. 

«3i:«]icxc9:c3i:3)i:}:iic:tc:(c:{:3!(](c:icsjc:9e:tc:tc3i:4(4c4c4(«3i(4c4c4c4c4c4c##4:4c4c>;t4c4c4c4c4‘4‘>ic4c4c>;c4c4c4c4‘4c:}:4c4c4c4c4c 

c2proc  = 

sysini t2  [code [a b [4391 1  .data  [ab  [S00] ,m  [0] ,ad [82] ] ,map [all] ] , 
sysdev . 
asmr out , 
gatemod 


3tc:9;3^::e:tc:{e:tc:{:3ie:9c:}c:9:3!:4c4c4:3!c4‘4‘4c4c3ic4c4c4:4c4c4c4c4c4c4c4c4c9;c4c4c4c4(4c4c>ic4c4:4c4c#4:>;cs!c3ic4t4c4:4<4caic4c4c4c 

sjc  sjc  :{t  ^  3^  jjc  jjs  Jl!  lie  jje  jjc  3;s  :;s  s;;  #  sis  j|i  jjt  j;;  5!c>!«  jH  s;,- :)e  j!«  #  <s  s}t  3{e  Jic  ^  sje  sjt  s[i  j{f  >;<  !{c>:t  s;t  sje  :{£  s;:  <c j;;  sjc  !{e  >;j  :;s  >;e  :{e  #  Jj:  ;;s  :;t  s;e  :;c 5;c  sji 


Cluster  2  RELATION.DAT  file 


This  file 

keeps  the 

data  used 

to  build 

the  relation 

^  S|C 

4C4C4C 

table : 

4c4t4C 

4S4C4C 

4C4C4C 

4c  4c  4c 

eve  id 

numdat 

noint 

Qlen 

bytes 

3|C  7j£ 

4«4c4c 

4c4C3)c 

4:4c  4c 

col 

col 

col 

col 

col 

4C4C4C 

4c  4: 4c 

5 

15 

25 

35 

45 

sic  4c  sic 

4c4c4(4c4c4c3!c4c4c4c4c4c4c4c4c4!4c4c4c4c4c4c4c4c4c4c4c4c4c3icsic4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c3ie4c3ic4c4c3i:4c4c4cst:si: 

01 

1 

8c58 

50 

6 

05 

1 

8dS4 

20 

3 

03 

1 

9dcd 

50 

9 

00 

0 

0000 

00 

0 

:{s  #  :0t  Us  jjt :(« #  :jc  # #  Jts  #  sic  #  #  *  #  jjc  <;  4s  >}: :{:  #  5}e  #  #  #  sje  jjc  3(6  jJ;#  >)t  J.'c  4t  4c  #  *  sjc  4c  4c  #  sis  Jit  4f  4t  #  #  sic  4t  4c  *  sH  #  «  4:  >!<  #  51= 

3ts  3;s  3tc  3{S  3(C  4c  3is  sis  3(S  sic  4c  sis  3ts  3tc  3tc  sic  3{C  SjC  39c  39E  S|C  :;c  3(S  Sic  sgs  4C  3{<  39c  sgs  >)c  >is  3jc4s  sje  3(e  ;CC  9  3tc  >is  3tc  3(C  3jc  3ts  3lic  >ic  3(C  34c  SifS  3;c  sic  3l)C  3(C  >ic  4:  4c  >jc  34c  SjS  sic  >iC 


<'>5'*  Cluster  2  ADDRESS.DAT  file 

4es^4« _ 4c4es;c 


4C4C4C  This  file  keeps  the  number  of  group  addresses, 

the  cluster's  groun  address (e s )  ,and  the  cluster's  **'*=*' 
4cs!t4e  source  address. 

S|c4e4c4c4c4cs{csic4e4c4e3i(4c>;c4:4c4c4c4:4c4c4c4csic4cs!c4c4c4c4i4c4c3t:4c4c4c4c4c3;c4e4c4c4c4c4c3i:4csic4ts!c4c4c4c4c4c4c4c3(c4c4c 

1. 

'30000000'b, '00000010'b, 

'00000000'b, '00000010'b 


4t  4> «  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  41 4c  4c  Sic  sic  4c  4c  4c  4c  4c «  4c  sic  4c  4c4c  4c  4c  4c  4c  4c  3):  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  sje  4c  4c  sic  4c  4c  sje  4c  sic  4c  4c 
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«c  4r  :tc « 9}: :{( « lie  ^  #  jjcgc :(( >ic  Xc  sic  ){c  :jc  9',:  lie  #  ije  <c  ;}c  9;: ^  afc  :tc  It:  aSe  <c>;i  :tc  sic « :{( sfc  si:  3^  >;c  sjctojc  :tc:!c  ^  3tc  ^  ^  3;:  ^ ^  ^  3'<‘ 


SYSINIT2.PLI  fils 


9jc9ieaic 


««#  This  is  the  system  initialization  procedure  for 
♦**  cluster  2. 


:(c  steje  sic  9{c  3ie sic 3(c  :tc  sjc  >}:  Xc  #  sje  sje « ate :{:  sjc  :3c  si;  9)(  Xc :{( 9je  sic  99c  3jc Xe :{::(:  sic  14c :{( aicstc  si:  a;: :{(:{:  Xc  age 9i:  9te  :4e  sic  sjc  sjc etc  sic  :;c  sje  :«c 


sysinit2:  proc  options  (main)* 

^include  'sysdef .pli  ' ; 
j^replace 

E7C_TYP5  hy  "00'b4; 

/*  main  */ 

call  def ine_cluster  ('0002'h4)»  /*  must  he  called  prior 

to  creating  eve's  '*/ 

yagcatcagcaic  USER  ***^  / 

call  create_evc  (T^.ACK_IN)* 

call  create_evc  (TPACI_OUT); 

call  create  eve  (^1ISSILE_OR!)ER  IN); 

call  createlevc  {MISSILE_CRDERlOUT ) ; 

call  create_evr  (DELTA_IN); 

call  create_evc  (DELTA~OUT); 

/ajcaicstc  SYSTEM 

call  create_evc  (ERE_READ); 

call  create_evc  (ERB_WRITE); 

call  create_sea  (EPB_WEITE_REOUSST ) ; 

/♦  distrib.  map  called  after  eventcounts  have 
been  created  */ 

call  distribution_mao  {EVC_TY?E,  TRACK_0UT,  '0003'b4); 

/*  local  and  remote  copy  of  T?.ACK_IN  needed 
call  di St ribution_map  (EVC_TY?E,  MISS ILE_ORDER  IN, 

'0003'b4); 

/■'!=  local  and  remote  ropy  of  MISS  ILE_ORDER_IN  needed  */ 
call  create_oroc  ('fc'b4.  '80'b4, 

'26a5'b4,  '0B00'b4,  '006b'b4, 

'0459'b4,  '0800'b4,  '0800'b4); 
call  await  ('fe'b4.  '01'b4); 


end  sy5init2; 

sic  sic  Xc  9;:  sic  sic  sic  X:  X:  Xc  sic  a;:  sic  Xc  si:  3;;  ate  X:  sic XC  X:  sic  X:  sic  age  39c  39c  9]C  si:  X:  XC  sic  a;:  aic  a;:  ai:  9ic  3(C aic  aic  ate 39:  xc  si:  sj:  X:  s;:  X:  sic  sic  3;:  aj:  Xc  X:  x: 


^^4(:4c:gcit;j;:^3Sc:;c:tcXc:ti^Xc’i‘4>St3!‘3tc>:-^3e‘3!t3(tVX(^#9ici(c4ciet3icj^:Qci(C3»;>^9;e:(c9iC9;e3ie:te«:;cX(3;c:ii:{c:te:Ce:tE#9jc>!c«:>r  / 

/*=«'  SYSDEF  FILE  SYSDFF.PLI  David  J.  3F.EWEP  1  SEP  84  =«'=«'/ 
/>;«s:‘==========  ^=================:  ==========================«#  / 

/sci^t  This  section  of  code  is  ^iven  as  a  PLI  file  to  be  / 

/»!'*  %INCLUDE'd  with  MCORTEX  user  programs.  ENTRY  =“*/ 

/«*  ^declarations  are  made  for  all  available  MCORTEX 
/=***  functions.  ’*'*/ 

DECLARE 

advance  ENTRY  (BIT  (B)), 

/*  advance  (e vent_count_id )  */ 

await  ENTRY  (BIT  (3),  BIT  (16)), 

/*  await  ( event_count_id ,  awaited_value )  */ 

create_evc  ENTRY  (BIT  (S)). 

/*  create  eve  (event_count_id )  ’*'/ 

create  proc  ENTRY  (BIT  (9),  BIT  (9), 

BIT  (16),  BIT  (16),  BIT  (16), 

BIT  (16),  BIT  (16),  BIT  (16)), 

/*  create_proc  ( processor_id ,  processor_priority ,*/ 
/*  s taclc_pointer~hiffhest ,  staclc_seg,  ip  ’*'/ 

/*  code_se^,  data_ses,  extra_seff)  */ 

create_sea  ENTRY  (BIT  (3)), 

/*  create.  seo  ( sequence_id )  ’*'/ 

preempt  ENTRY  (BIT  (9)), 

/#  preempt  ( processor_id )  */ 

read  ENTRY  (BIT  (8))  RETURNS  (BIT  (16)), 

/*  read  ( event_count_id )  */ 

/#  returns  current_event_count  ’*'/ 

ticket  ENTRY  (BIT  (8))  RETURNS  >BIT  (16)), 
ticket  (  seauence_id  )  ’*'/ 

/*  RETURNS  un io ue_ticket_value  */ 

def lne_cluster  ENTRY  (bit  '16)), 

/*  def ine_cluster  ( local_cluster_address  )  ’*'/ 

distrlbution_mai)  ENTRY  (bit  (8),  bit  (3),  bit  (16)), 

/*  di stributi on_map  (dis t ributi on_ty?e ,  id, 

cluster  addr)  */ 


add2bitl6  ENTRY  (BIT(16),  BIT(16))  RETURNS  (BIT  (16)) 
/*  add2bitl6  (  a_16bit_#,  another_16bi t_# )  */ 

/*  RETURNS  a  16bit  #  +  another  16bit  #  */ 


^replace 


EVCSID  s  *** 

(1)  USER 

TRACK_IN  by  '01 'b4: 

TRACK  OUT  by  '02'b4 

MISSILE_OR!?ER_IN  by  '03'b4 

MISSILE_ORDER_OUT  by  '04'b4 

DELTA_IN  by  '05'b4 

DELTA_OUT  by  '?6'b4 

r*  (2)  SYSTEM 

ERB_READ  by  'fc'b4 

ERB  WRITS  by  'fd'b4 


SEQUENCER  NAMES 

(1)  USER 


(2)  SYSTEM  ’«'/ 

ERE  WRITE  REQUEST 


by  'ff'b4 


SHARED  VARIABLE  POINTERS 

fl)  USER 


/’>'  (2)  SYSTEM  #/ 

block_ptr_value 
xmi t_pt  r_value 
rcv_pt  r_value 

END  RESERVE 


by  'B000'b4, 
by  '8078'b4, 
by  '8666'b4, 

by  'FF?F'b4; 


« a^c  :4e  :(e  :0t  9«c  a9c  ^ sOe  sQc  :«c  a4c  sfe  9d:  a9e Xc  ait  9;c  :4e  ^  sjc  age  9;< 


\rVV.W  ■ 


4c  #  4c  4c  cjc  4>  4c  41 4c  4c  4c  4c  >!(  4c  4c  4c  4c  4c  4c  4c  4c  4e  4<  4c  4e  4e  4c  4c  4c  4c  4c  9ie  4c  4c  4c  sje  4c  4c  4c  4c  4c  4c  4e  4c  4c  4c  4c  3X  4c  4c  4c  4c  4c  4c  4c))c  i(c  4c  4c 

*»♦  NI3010.DCL  file  *’«'* 

4c4c4c4c4c4c4c4c4c4c4c4c4c4c4:4c4(4c4c4c4c4e4c4c4‘4>4‘4‘4c4c4c4c4c4c4c4c4c4:4c4c4c4c4c4(4c4c4c4c4c4c4c4c4c4c4c4‘4c4c4c4c 

;Kreplace 


/4. 


I/O  port  addresses 


These  values  are  specific  to  the  use  of  the  INTSRLAN 
NI301?  MULTIBUS  to  ETHERNET  interface  hoard.  Any  change 
to  the  I/O  port  address  of  '00b0'  hex  (done  so  with  a  DIP 
switch)  will  reouire  a  change  to  these  addresses  to 
reflect  that  change. 


c  ommand_ 

register 

by 

'b0' 

'b4. 

command_ 

status_register 

by 

'bl' 

'b4. 

transmit 

_data_regls  ter 

by 

'b2' 

'b4, 

interrun 

t  status  reg 

by 

'b5' 

'b4. 

interrupt_enable_ re sister 

by 

'b6' 

'b4. 

high_byt 

e_^ount_reg 

by 

'be ' 

'b4. 

1 cw_byte 

_coun  t_reg 

by 

'bd' 

'b4. 

ID 

of  I/O  port  addresses  */ 

/*  Inte 

rrunt  enable  status 

regis 

;ter 

value 

disable 

ni3010_interrupts 

by 

'00' 

'b4, 

ni3010_r 

ntrpts~disabled 

by 

'00' 

'b4. 

receive_ 

block_available 

by 

'04' 

’b4, 

transmit 

_ima_done 

by 

'06' 

’b4. 

receive_ 

dma_done 

by 

'07' 

’b4. 

/’*'  end  register  values  ’*'/ 


/*  Command  Function  Codes 


'nodule_interface_loopbaclc 

internal_loopbacic 

clear_loopback 

eo_  of f 1 ine 

go_online 

onb oar l_dl agnostic 
clr_lnsert_source 
load_transmit_data 
1 oad_and_send 
1 oad_groun_ad dresses 
reset 


by 

'01' 

'b4, 

by 

'02 

'b4. 

by 

'03' 

’b4. 

by 

'08' 

'b4. 

by 

'09' 

'b4. 

by 

'0a' 

'b4. 

by 

'0e ' 

'b4. 

by 

'23' 

'b4. 

by 

'29' 

'b4. 

by 

'2a' 

'b4. 

by 

'3f ' 

'b4; 

/’*'  end  Command  Function  Codes  */ 

4c4c4c4c4c4c4c4c4c4c4c4c4c4c4:4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4(4c4c4c4c4‘4c4c4c4c4:4c4c4c4c4c4:4c4:4c4c4c4c4c4c4c4c 


«4c4c4c4c4c4c4c4:4c4c4c4c4c4!4c4c4c4t4c4c5{c###4c4c4c4c4c4c4c4t4c4e4c4c4es!<4c4c4c4c4c4c4c4c4c4c4c4cs!s4c!lc4t4c4c4t>!cs;c 

*’«'*  SYSDEV.PLI  file  (driver) 

;ic  3jc:(:  14c  9ti  Xc  39c  :;c  ^  3it  3tc :{( >;t 9li  4c  4c  4c  4c  4c  >;<  4c  4c  4c  4c  4c  4c  4c  3tc  Vc  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  Sic  :(c  sjc  4e  3ic  Xc  >ic  :ic  :{c  jJOc 


syslev:  procedure* 


/*  Date; 


25  N0VEM3EH  1985 


Programmer:  Reinhard  HAEGER 


Module  Function:  To  serve  as  the  Ethernet  Communication 

Controller  Board  ;nI3010)  device 
handler  (driver).  This  process  is 
scheduled  under  MCORTEX  and  consumes 
Ethernet  Reauests  Packets  (SRP) 
generated  by  the  SYSTEM$IO  routine  in 
LEVEL2.SRC. 

It  creates  a  relation  table  that  keeps 
information  about  the  interrelationship 
between  eventcounts  and  user  shared 
lata,  and  uses  this  information  for 
producing  and  processing  Ethernet 
messages . 


This  driver  is  the  version  urovided  by  David  Brewer 
modified  in  order  to  ensure  system-wide  data  sharing. 
The  Transmit_Data_Block  and  the  Receive_Data_Block  were 
changed  to  keep  1500  bytes  of  data. 

New  orocedures  Make_Table  and  Make_Me5Saffe  were  added, 
and  procedure  Process_Packet  was  comuletely  changed  to 
provide  cluster  external  user  shared  data  exchange. 
Procedure  Transmi t_Packet  was  modified  to  provide 
flexible  exact  message  length  to  the  ECCB  if  the  length 
is  greater  than  60  bytes,  and  minimum  message  length  if 
the  message  is  60  bytes  or  less. 

4C/ 


^replace 

evc_type 
erb_bi bck_len 
erb_bl ock_len 
infinity 


by 

'00'b4 

by 

20, 

ml 

by 

19, 

by 

32767; 

^include  'sysdef  . pli  ' I 


DECLARE 


1  erb{ 0:erb  ■block_leii_ml  >  based  (block_ptr) 
2  command  bit  (8), 

2  type_name  bit  (8) , 

2  name_value  bit  (16), 

2  remote_addr  bit  (16), 

1  tran smi t_data_block  based  (xmit_ptr). 


2 

dest ination_address 

a 

bit 

(8)  , 

2 

lest ination_addr ess 

_b 

bit 

(B). 

2 

dest ination_address 

c 

bit 

(8), 

2 

destina tion~address 

_d 

bit 

(8), 

2 

destination  address 

e 

bit 

(8)  , 

2 

destina  tion_address 

bit 

(8)  . 

2 

source_address_a 

bit 

(8)  , 

2 

source_address_b 

bit 

(8), 

2 

s  ource_address_c 

bit 

(8), 

2 

source_address~d 

bi  t 

(8). 

2 

source_ addressee 

bit 

(8)  . 

2 

source_address~f 

bit 

(8)  , 

2 

type_field  a 

bit 

(8)  . 

2 

tyne^field  b 

bit 

(8), 

2 

data  (15007 

bit 

(8), 

1  receive_data  block  based  (rcv_ptr), 


2 

f  rame_s  tatus 

bit 

(3) 

2 

null_by te 

bit 

(8) 

2 

f rame_l enffth_lsb 

bit 

(B) 

2 

frame  length  msb 

bit 

(3) 

2 

dest inati on_addr ess 

a 

bi  t 

(3) 

2 

dest ina  ti on_address 

7b 

bit 

(B) 

2 

dest inati on_addr ess 

c 

tit 

(8) 

2 

destina  tion_address 

_d 

bit 

(3) 

2 

dest ina tion_addr ess 

e 

bit 

(8) 

2 

destination  address 

_f 

bit 

(8) 

2 

s  ource_addres5_a 

bit 

(3) 

2 

sourre_address_b 

bit 

(8) 

2 

source_address_c 

bit 

(8) 

2 

source^ addressed 

bit 

(3) 

2 

source_address_e 

bi  t 

(S) 

2 

source_address_f 

bit 

(9) 

2 

type_field_a 

bit 

(8) 

2 

type  field  b 

bit 

(8) 

2 

datari500) 

bit 

(S) 

2 

crc_msb 

bi  t 

(3) 

2 

crc_  upper _mlddle_ 

.byte 

bit 

(8) 

2 

crc_lower _middle~ 

'byte 

bi  t 

(8) 

2 

crc  Isb 

bit 

(8) 

e_ptr  pointer, 
erp_vect(4)  bit  (9)  based  (e_ptr), 
(maxqbytes .bytecount )  fixed  bin  (15), 

1  rel_tab(100) , 

2  evc_id  bit  (8), 

2  numdat  fixed  bin  (7), 

2  data ( 10 ) , 

3  point  pointer, 

3  qlen  fixed  bin  (7), 

3  bytes  fixed  bin  (15), 

3  next_out  fixed  bin  (7), 

3  next_in  fixed  bin  (7), 

(xmit_otr,  rcv_ptr ,bloclt_ptr)  pointer, 
index  fixed  bin  (15) , 

(addr_e,  addr_f)  bit  (8),  , 

address  file, 
copy_ie_register  bit  (8), 

( clnster_addr ,erb_wri te_value , i )  bit  (16), 
( .1,k)  fixed  bin  (15) , 
re«_value  bit  (8)  , 

wri te_l o_port  entry  (bit  (8),  bit  (8)), 
read_io_port  entry  (bit  13),  bit  (8)), 
initialize_cpu_interrupts  entry, 
enable  cpu_lnterrunts  entry, 

disable_cpn_interrupts  entry, 

write_bar  entry  (bit(16)); 

/’*'  end  declaration  */ 


^replace 

/*  codes  soecific  to  the  Intel  8259a  Prosrarrmable 
Interrupt  Controller  (PIC)  */ 


icwl_por t_addres5 

by 

'C0 

'b4. 

/« 

note  that 

icw2_port_aldress 

by 

'c2 

'b4. 

/* 

icw2, icw4 

,*/ 

icw4_por t _address 

by 

'c2 

'b4. 

/* 

/# 

/ 

and  ocw 
use  same 
port  addr 

*/ 

ocw_port_addre5S 

by 

'c2 

'b4. 

/♦  note:  icw  ==>  initialization 

c  ontr ol 
word 

ocw  ==>  operational 
command 

word  '*  / 


Icwl 


by  '13  b4 


/*“  single  PIC  configuration,  elge 
triggered  input 

icv2  by  '40 'b4, 

/*  most  significant  bits  of  vectoring 
byte;  for  an  interrupt  5, 
the  effective  address  will  be 
(icw2  +  interrunt  # )  ’*'  4  which 
will  be  (40  hex  +5)  *  4  =  114  hex 

#/ 

icw4  by  '0f'b4. 

/*  automatic  end  of  interrupt 
and  buffered  mode/master  "*/ 

ocwl  by  '8f'b4; 


/*  unmask  interrupt  4  (bit  4),  *"/ 

/*  interrupt  5  (bit  5),  and 

/*  interrupt  6  (bit  6),  mask  all  others  */ 


end  8259a  codes  ’*'/ 


/♦  include  constants  specific  to  the  MI3010 
board 

^include  'ni3010 .del '? 

/*  ^'ain  Body 
/*^  check  message 

put  skiT)(2)  list( 'starting  make_  table ') »  ’*'/ 
call  make_tatle; 

/♦  check  message 

put  skip(2)  list( 'make_table  done')*  "/ 

call  wri te_io_por t ( interrupt_enable_reglster , 

d i sable _ni 301 0_interrupts ) ; 
call  ini tialize_pic; 
call  initialize_cpu_interrupts; 

call  read_io_port  (command_status_register ,reg_value ) ; 
call  perf orm'command  (reset); 


call  proeram_^roup_addresses ; 

/*  assisniTients  to  the  source  and  destination  address 
fields  that  will  not  change 

call  perf orm_comtTiand  (clr_in sert_source )  J 
/♦  NI3010  performance  is  enhanced  in  this,  mode 


unspec (block_ptr)  =  block_ptr_valne ; 
unspec { rcv_ptr )  =  rcv_ptr_varue ; 
unspec(xmit_ptr)  =  xmlt_ptr_value; 

/*  maice  one  time  assignments  to  transmit  data  block  ’!'/ 

transmlt_data_block.destination_address_a  =  '03'b4; 
transmit_data_block.destination_address_b  =  '00'b4; 
tran5mit_data_block.destination~address~c  =  '00'b4; 
transmit_data_block.destination_address_d  =  '00'b4; 
transmit_data_block  .source_address_a  =  '’03'b4; 
transmit_data_block .source_address_b  =  '00'b4; 
transmit_data_block  .source_address_ c  =  '00'b4; 
transmit_data_block.source_address_d  =  '30'b4; 

/*  get  the  local  cluster  address  -  file  was 
opened  In  proc  pr ogram_group_add resses  */ 

get  file  (address)  list  (addr_e,  addr_f)» 
transmit_data_block.source_address  e  =  addr_9; 
transmit_data_block.source_address]_f  =  addr_f; 

cluster  addr  =  addr  e  ! '  addr_f; 

put  skip  (2)  edit  CLUSTS?.  ' , r lus te r_addr , 

'  Initialization  Complete 
(col( 15) ,a, b4(4) .a ) t 

i  =  '0001  'b4; 

call  per f orm_com’nand  (go_online); 

/’*'  at  this  point  ccpy_i9_reff  =  ?.BA  .  but 
ie_reg  on  NI3010  is  actually  disabled 
call  disable_rpu_lnterrupts» 

do  k  =  1  to  infinity* 

/*  note:  interrupt  not  allowed  during  a 
call  to  MCCRT3X  primitive 

erb_wri te_value  =  read (EBB_WHITE) ; 

/*  In  the  MITRACE  version  of  the  RTOS 
all  primitive  calls  clear  and 
set  interrupts  (diagnostic  message 
routines),  so  the  NI3010  interrupts 
must  be  disabled  on  entry  to  MXTRACE 


do  while  (erb  write_value  <  i ) ; 

/♦  busy  waiting  */ 
erb_wri te_value  =  read(ERB_WRITE) i 
copy_ie_regi ster=receive_bl ock_available ; 
call  write _io_port ( in terrupt_enable_reRi ster , 

receive_block_available ) » 
call  enatle_cpu_iiiterrupts f 
/*  if  a  packet  has  been  received , this 
is  when  an  interrupt  may  occur  -  can 
see  that  outbound  packets  are  always 
favored.  */ 

do  .1  =  1  to  1000; 

/*  interrupt  window  for  packets  received  */ 
end;  do  ,]  */ 

call  disable_cnu_interrupts; 
if  ( cony_ie_re^ister  =  receive_dma_done >  then 
do; 

/*  receive  DMA  operation  started,  so  let 
finish.  =*'/ 

call  enable_cpu_interrupts ; 

do  while  { copy_ie_re?ister  =  receive_dma_ione ) ; 

end ; 

call  disable_cpu_interruDts; 
end;  ift 

copy_ie_reai  ster  =  disable_ni3010_interr'jpts ; 
call  write_io_port(  interrupt_enabl9_rei^ister , 

di  sab  le_nl3010_i  liter  runts  ) ; 

end;  /*  busy 

/*  ERB  has  an  ERP  in  it,  so  process  it 
/*  no  external  interrupts  (REA)  until 
the  ERP  is  consumed  and  the  packet 
eets  sent 

index  =  mod (( fixed ( i  )  -  1),  erb_block  len  ) ; 

/<*  32k  limit  */ 


transmit _dat a_bl ock.destination_add re ss_e= 

substr(erb( index)  .remote_ddd r , 
transmit_data_block. des  tina ti on_address_f  = 

substr( erb ( index ) .remote  addr, 


1,3); 
9,6) ; 


/*  put  overlay  over  ERP  */ 
e  ntr=addr ( erb ( index ) .command ) ; 


call  make_messa?e; 
call  advance  ( ERB_READ) ; 

/*  caution  here  !  ! !  ! 

an  ADVANCE  will  result  in  a  call  to  VP$S CHEDULER , 
which  will  set  CPU  interrupts  on  exit. 

It's  the  reason  NI3010  interrupts  are  disabled 
first  in  the  Do  While  loop  above.  */ 
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/*  packet  ready  to  ,  so  send  It  */ 
call  transmi t_packet  (bytecount); 

/*  cooy_ie_rei?lster=RBA,  but  not  actual  rei^ister  =*'/ 
call  disable_c pu_interrupts » 

/*  settine  un  for  next  ERP  consumntion  */ 

1  =  add2bltl6(i,  '0001'b4); 

end;  /♦  do  forever  */ 

/*  end  Tiain  body  '*/ 

make_tatle:  procedure  ; 

declare 

relation  file, 

(.],i)  fixed  bin  (15), 
eof  bit(9) ; 

onen  file  (relation)  strea-n  input; 
i=0; 

sof='0"b4; 

do  while  (eof=  '0  'b4)  ; 
i=i+i; 

/■»  read  data  from  relation.dat  file  ’*'/ 
set  file  (relation)  edit (rel_tab( i ) .evc_id , 

rel_tab' i ) .numdat ) 

(column (5 ) , b4( 2 ) , column { 15 ) , f ' 2 ) ) ; 
do  J=1  to  ( rel_tab ( i ) .numdat ) ; 

/*  read  data  for  all  related  items  */ 
get  file  (relation)  edit 

(unspec ( rel_tab ( i ) .data ( j ) .poin  t ) , 
rel_tab(  i  )  .data( .) )  .alen  , 
rel_tab(i) .data(j) .bytes) 

(column (25) ,b4(4) , column (35) ,f (4) , column (45) ,f (4) ) ; 
maxq byt es=max (maxabytes, 

rel  tab(l).iata(j). bytes* re l_tab(i).data(j) .alen) ; 

end; 

/*  if  sentinel  is  reached  */ 
if  rel_tab(i ) .evc_id  =  '00'b4  then 
do ; 

eof='l  'b4; 

put  skip  11  St ( 'longest  data  aueue  at  this  cluster:', 
maxabytes, '  bytes ') ; 

end ; 
end; 

end  make  table; 


make_tnessage :  procedure  J 
declare 

dat_ptr  pointer, 

dat_vect ( 1500 )  "bit  (3)  "based  (dat_ptr)  , 

(neit_out ,  r,  .1 )  fixed  bin  (7), 

(off  .start  .last  ,1c)  fixed  bin  (15); 

/’*'  checlc  for  eve  */ 
if  erp_vect (1 )=EVC_TYPE  then 
do ; 

bytecoant=4; 
do  lc=l  to  4; 

put  eve  info  into  data  field  '^/ 
transp’it_data_block.lata(k)=erp_vect  (k)  ; 
end; 

/«  check  messa^re 

put  skip  lis t ('::::', transmit_data_block. data ( 1 ), ' 

transmlt_data_block.data(2) 
transniit_data_block.data  (3) ,  ' 
transmit_data_block .data (4) , ' 

r=l ; 

/*  find  respective  relation  table  entry  */ 
do  while  (  ( rel_tab(  r)  .evc_id  erp  vect(2))  & 

(rel~tab(r)  .evc3<i  '00^b4)); 

r=r+i; 
end; 

/*  if  eve  entry  */ 
if  rel_tab (r )  .eve  id  '00'b4  then 
do; 

/*  for  every  related  ite-n  ”'/ 
do  J=1  to  rel_tab(r) .numdat; 
start  =  bytecount  *  i;  find  where  to  put  ’*'/ 

last=rel_tab(r )  .data(  J)  .bytes;  /’*'  how  lor.^  it  is  ’*^■1 
bytecount=bytecount  +  last;  /*  keep  track  */ 
dat_ptr=rel_tab^r)  .data(j  )  .point;  /’^'alisr.  datvect*''/ 
next_out=rel_tab  (  r )  .data(,^)  .next_out; 

/*  compute  offset  of  item  in  data  queue  '*/ 
of  f=(  rei_tab  (  r  )  .data  (  J )  .bytes  ="  next_cut)  +  i; 

/’*'  compute  next  slot  number  to  eo  ’*'/ 
rel_tal(  r )  .data ( ,5 )  .next_out=mod  •  next  out  +  1, 

rel_tab(r7.data(j).alen); 

do  k=0  to  (last-1); 

/’*'  put  item's  bytes  into  data  field  */ 
transmi t_la ta_block .da  ta(k+start )=da t_vect ( k+of f ) ; 
end; 
end; 
end; 
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/♦  compute  total  bytecount  for  message  ♦/ 
bytecount=b.ytecount  +  14; 
end; 

else  do;  /’*'  if  rot  eve  ’*'/ 
end; 

end  make_iT)essa«e ; 

initialize_pic :  procedure; 

DECLAP  E 

wri te_io_port  entry  (bit  (8)  ,  bit(8)); 
call  write_io_oort  ( icwl_?ort_address  ,icwl ) ; 
call  write_io_?ort  ( icw2_port_addre5S , icw2 ) ; 
call  wri  te_i  o_port  (  icw4_port_a'idress  ,  icw4 ) ; 
call  wri te~l o_port  (ocw_port_address , ocwl ) ; 

end  initialize  pic; 


/#<e#5(cj{t5!c#5!!s!eJ!tst:>!cJ0c>!t))n)t5ji3ie#5:sSrSoJ!ts)eiSs!!!!tJjtsies!e5!;s!c^e5!ts|«!!c##s!:s)!>!:>;«:!t«!i«»!es^si:>r#slcs!e5;:s{es;t5S5!=*  / 


perf orm_corr;mand :  procedure  (command); 

DECLARE 

command  bit  (9)  . 
re«_value  bit  (8)  , 

srf  bit  (8)  , 

wri te_io_port  entry  (bit  (8)  ,  bit  (8)  ), 
read_ro_port  entry  fbit  (3)  ,  bit  (8)  )♦ 

srf  =  '0'b4; 

call  write_lo  uort  (commanl_re2ister .command  ) ; 
do  while  ((srf  &  '0l'b4)  =  '00'b4); 

call  read_io_port  ( interruut_status_rei2,  srf); 
end;  /«  do  while  =>'/ 

call  read_io_port  ( command_status_reffister ,  re?_value); 
if  (ree_value  >  '01'b4)  then 
do ; 

/*  not  (SUCCESS  or  SUCCESS  with  Retries)  ’*'/ 
put  skip  edit  ('#*’!'  ETHERNET  Board  Failure 
(col(20),a); 

/’*'  when  this  occurs,  run  the  diagnostic 
routine  T3010/Cx,  where  x  is  the 
current  cluster  number  / 

s  t  ou ; 

end;  /*  itd  */ 
end  per f orm_command  ; 
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transmit_packet :  procedure  (byte_count)  external; 


DECLARE 

p  pointer, 

byte_count  fixed  bin  (15)  , 
bytevector ( 2)  bit  (8)  based  (o), 
srf  bit  (3)  , 
re^_value  bit  (8)  , 

write_io_port  entry  (bit  (8),  bit  (8)  ), 
read_io_port  entry  (bit  (3),  bit  (3)  ), 
enabre_cpu_interrupts  entry, 

disable_cpu_interrupts  entry, 

write_bar  entry  (bit(16)); 

/*  besln  «/ 
srf  =  ''0'b4; 

call  write_bar  (xmit_ptr_value) ; 

/*  if  messaae  longer  than  minimum  size  */ 
if  (byte  count  >  60)  then 
do; 

p=adlr (byte_count ) ; 

/*  call  with  exact  bytecount  */ 
call  write_io_port(hiffh_byte_count_reff, byte vector (2) ) ; 
call  write_io_port  ( low_byte  count_re5:,bytevector(  1 ) ) ; 
end; 

/*  if  message  is  not  longer  than  minimum  size  */ 
else  do; 

/*  call  with  minimum  bytecount  of  60 
call  wrlt9_io_port( high_byte_count_reg, '30 'b4) ; 
call  write_io  _por t ( low_byte_count_reg , '3c ' b4) ; 
end; 

cony_ie_register  =  t ran5mit_dma_done ; 

call  wrlte_lc_port (interrupt_enable_register , 

t  ransmit_dma_done  ) ; 
call  enable_cpu_interrupts; 

do  while  ( copy_ie_reglster  =  tran5mit_lma_done) ; 
end;  /*  loop  until  the  interrupt  handler 
takes  care  of  the  TDD  interrupt  - 
it  sets  copy  ie_register  =  RBA  */ 
call  perf orm_command  ( Ioad_and_send  ) ; 
put  skip  li St ( 'transmitting') ; 
end  transmit_packet ; 


HL_interrupt_haiidler:  procedure  external; 

/’*'  This  routine  is  called  from  the  low  level 
8086  assembly  language  interrupt  routine 

DECLARE 

write  io_port  entry  (hit  (8),  bit  (8)  ), 
read_ro_port  entry  (bit  (6)  ,  bit  (8)  ), 
enable_cpu_interrupts  entry, 

disable_cpu_interrunts  entry, 

write_bar  entry  (bit(16)); 

/*  begin  */ 

call  write_io_nort (interrupt_enable_register, 

disable_ni3010_interrupts  ) ; 

if  (copy_ie_register  =  receive_block_available )  then 
do; 

call  write_bar  ' rcv_ptr_value) ; 

call  write_lo_port(high~byte_count_reg, '05'b4) ; 

call  write_io_port(low_byte_count_reg, 'f2'b4); 

/*  initiate  receive  DMA 

copy_ie  register  =  receive_dma_dor.e ; 

call  wrrte_io_port ( interruot_enable_register  , 

receive_dma_done ) ; 

end;  do  */ 

else 

if  (ccpy_ie  register  =  receive_dma_done )  then 
do; 

call  process_paclcet ; 

copy_ie_regls  ter  =  recei  ve_bloc!c_a  vai  lable  ; 
call  write_io_port  (  ir.terrupt_enable_register  , 

receive_block_a vail  able ) ; 
end;  /=*'  if  then  do  */ 
else 

if  (cony  ie_register  =  transmi t_dma_done )  then 
do; 

coDy_ie_register  =  receive_block'_avai  lable  ; 

/*  NI3010  interrunts  disabled  on  entry  */ 
end;  if  then  do 

end  HL_lnterrupt_handler; 


se 


process_paclcet :  procedure? 

DICLARS 

evci 1  tit  ( S ) , 
local_evc_value  bit  (16), 

(dat_ptr,B)  pointer, 
remote_evc_value  bit  (16)  based  (p), 
dat_vect ( 1500)  bit  (8)  based  (dat_ptr), 

(off .start, last ,k)  fixed  bin  (15), 

(next_in , r , j )  fixed  tin  (7); 
put  skip  list ( 'receivi ' ) ; 
check  for  eve 

if  receive_data_block. data ( 1 )=evc_type  then 
do; 

p  =  addr ( receive_dat a_block .data ( 3) ) ; 
evcid=receive_'lata_block.data(2); 
local_evc_value  =  read(evcid); 
if  local_evc_value  <  rernote_evc_  value  then 
do  i 
r=i; 

/*  find  eve  entry  in  relation  table 
do  while  (  ( rel_tab  ( r )  .evc_id  evcid)  S. 

(  rel_tab  ( r  ) .  evc_id  ''=  '00'b4)); 

r=r-^l ; 
end? 

if  rel_tab( r )  .evc_id  '00'b4  then 
do ; 

bytecount=4;  /*  jump  over  eve  info  */ 

do  j=l  to  rel_tab( r ) .numdat ; 

start=bytecount+l ;  /*  compute  start  of  item 

last  =  rel_tab  ( r  Kdata  (  J  )  .bytes ;  /'•*'  and  length  '^/ 
bytecount=byteeount+las t;  /*  and  item's  end  “/ 
next_in=rel_tab'r).data(j).next_in; 

compute  offset  in  data  oueue  '■'/ 
of f  =  (  las  t’*‘next_in  )  +  i; 

/’*'  compute  next  slot  numbe’'  to  fill  */ 
rel_tab(r).data(j).next_in=mod'next_in+l, 

rel_tab( r) .data(  j  )  .alen) ; 

da  t_'Dtr=rel_ta  b  (  r )  .da  ta  {  j  ) .  no  I  nt ;  alid?n  datvect’*'/ 

do  k=0  to  (last-1); 

/*  put  item  bytes  into  data  oueue  */ 
dat_vect(k+off)  =  receive_data_block.data''k+start); 
end ; 

end; 
end ; 
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/*  update  local  eve  value  */ 
do  while  ( local_ev c_value  <  remote_evc_value  ) ; 

call  advance  (evcid)*  ,  ,  x 

local_ev c_value  =  add2bitl6( local_evc_value ,  b4); 

end ; 
end* 

else  do;  /*  if  not  eve 
end; 

call  disable  c  ou  interrupts; 


end ; 


end  orocess  oacicet; 


orosra'n_group_aldres  se s  :  nrocedure ; 


EECLARE 


1  2rouT)_addr ( 40 )  based  (eroup_ptr), 


2  nc_2roun_f ield_a 
2  mc^f'roup^f ield~b 
2  'nc_2rouo_f  teld_  c 
2  mc_2roup_field_d 
2  mc_2roup_f ield_e 
2  mc^fifroup'f ield'f 


bit  (S), 
bit  (8), 
bit  (8), 
bit  (8 ) , 
bit  (9), 
bit  (8); 


EECLARE 


(group_ptr,p)  ooirter, 

(field_e,  field_f)  bit  (8). 
bit_8_2roups  bit  (9)  based  (p), 

(  i  ,  nun_2roups  .2r  oups_tifres_6)  fixed  bin  (?); 

unsoec(2roup_t)tr )  =  xrrit_ptr_value; 
open  file  (address)  stream  input; 

(get  file  (address)  list  ( num^gr  oups ) ; 
d  0  i  =  1  1 0  num  groups  ; 


group_addr  x i ) .mc_group_f ield_a 
gr ou  p_addr ( i) .mc_group_field_b 
group_addr( i ) .Tc_group_f ield_c 
group_addr ( i) .mc_group_field_d 


'03'b4; 
'00 'b4; 
'00  'b4; 
'00  'b4; 
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get  file  (address)  list  (field_e,field_f ) ; 
?rouT)_addr(  i  )  .mc_ffroup_f ield_e  =  field^eJ 
group_addr( i ) .mc_group_f ield_f  =  field_f; 


end ; 


/*  do 


call  disa'ble_cpu_interrui)ts; 

call  write_bar  ( Tmit_ptr_value ) ? 

call  write_lo_port(high_'byte_count_reg,  '00''b4)f 

«roups_times_6  =  6  *  n'jm  croups; 

p  =  addr  (groups_tiTies  _6'} ; 

call  write_io_port(  low  ■byte_count_reg,  bi  t_8_groups  ) ; 

coDy_ie_regis ter  =  t ransmi t_dma_ione; 

call  wrrte_io_po rt  (interrupt__enable_ register, 

transmit_dma_ione ) ; 
call  enable_cpu_interrut)ts; 

do  while  (  copy_ie_register  =  transmi  t_lma_dor.e  ) ; 
end*  /*  loop  until  the  interrupt  handle’' 
takes  care  of  the  TDD  interrupt  - 
it  sets  CO?Y_IE_aEG  =  REA  */ 

call  perf or'Ti_command  ( 1  oad_group_ad dresses  )  J 


end  program_group_addresses ; 


end;  /*  system  device  handler  and  packet  processor 
(driver)  */ 


:{e  )is  3^  #  sjt  3^  #  #  >)t  #  J(e  >;«  j)c  3j(  j;*  #  )jc  j,-!  #  jje  >;<  jp  jl*  #  >}:  >it  #  ){cijc){c  :)c  ){c  Mc  i;t  j?  *  #  j?  sjcjf:  ;ie  5!t  si*  >jt  sit  3ie  5is >:t  s:*  5!-!' # 

ASMHOUT.Aee  file 

sjc  sj:  sjt  sjt  :I;  5|<  ;!t  sit  sjt  sit  sic 3{:  s(:  s;s  si:  :(t  s)e  si:  sic  sit  sjt  s{t  sjt  >!e  sic  si:  sic  s}:  sjt  si:  sit  s.-  si: !{:  si:  s{:  sic  if.  if  if  s|;  si;  si:  sic  ii  if  s):  si;  si:  si:  i:  si; 


extrn  hl_i nte rrupt_ handler  ;  far 

Dublic  wri te_io_por t 
public  read_io_port 
nublic  write_bar 

public  initialize_cpu_interrupts 
public  enable_cpu_interrupts 
public  lisable_cpu  interrupts 

•  ifif  if  if  nif  ifif  if  if  iiiiiififiHfif  if  ififif  if  ifif  if  if  ififif  ififififififif  if  if  ififififif  if 


v-> k'' V  ' 


wrlte_lo_port : 


;  Parameter  Passing  Specification: 

;  entry  exit 

;  parameter  1  <port  adlress>  <'unrhangei> 

?  parameter  2  <value  to  be  outputted>  <unchdiige'i> 

dseg 

port_address  rb  1 


mov 

mov 

mov 

mov 

mov 

mov 

mov 

out 

pop 

ret 


cseg 

push  bx !  push  si!  nush  1x1  push  ax 
si,  [bx] 
al,  [si] 

port_address ,  al 
si,  2[bx3 
al,  [sil 

oor t_address 
00h 
al 

pop  dx !  poo  si!  pep  bx 


11-, 
dh, 
dx , 
ax ! 


read_io_port : 

Parameter  Passing  Soecif ication 

entry 


exit 


parameter  1 
parameter  2 


<oort  address> 
<meaningless> 


<unchangei> 
<register  value' 


cseg 

push 

bx! 

push  si!  rush  dx!  push  ax 

mov 

si , 

[bx] 

mov 

al , 

[sil 

mov 

Dort 

address,  al 

mov 

SI  , 

2[bx] 

mov 

dl. 

port  address 

mov 

dh , 

00h 

in 

al. 

dx 

mov 

[sil 

,  al 

poo 

ax ! 

poo  dx!  ooo  si!  000  bx ! 

ret 

S4 


write  bar: 


Parameter  Passing  Specification 

parameter  1  (and  only):  the  address  of  the  data  bloclc 

to  be  transmitted  or  received. 


dseg 

e_bar_port 

eou 

0b9h 

h_bar_port 

eou 

0bah 

l_bar_port 

equ 

0bbh 

temo_e_byte 

rb 

1 

temp  es  rw 

1 

cse? 


J  This  module  comuutes  a  24  bit  address  from  a  32  bit 
;  address  -  actually  it's  a  combination  of  the  2S 
i  register  and  the  IP  passed  via  a  parameter  list. 


add_l : 
no  add 


push  bx ! 

1  push 

ax !  push 

mov 

dx , 

0800h 

mov 

es. 

dx 

mov 

temp 

es  ,  es 

mov 

lx, 

es 

mov 

si , 

[bxl 

mov 

ax. 

[sil 

mov 

cl. 

12 

shr 

lx , 

cl 

mov 

temp 

e_byte 

f 

mov 

lx. 

temp_e 

s 

mov 

cl  , 

4 

shl 

dx. 

cl 

add 

ax , 

dx 

.Inc 

no  add 

inc 

t  emp_ 

e_byte 

:  out 

l_bar 

port , 

al 

mov 

al ,  a 

h 

out 

h_bar 

_Port , 

al 

mov 

al ,  t 

em  p_s_ 

byt 

out 

e_bar 

_port , 

al 

pop 

si  !  po 

p  dx ! 

POP 

ret 

oush  es !  uush  dx!  push  si 
shared  memory  segment 


POO  cx 1  poo  ax! 


pop  bx 
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* p  r^  * 


“.W  r  xVj  rJ.  •  , 


initial!  ze_ci)u_i  n  ter  runts  : 

;  (Module  Interface  Specification; 

»  Caller:  Etttertest (?L/I )  Procedure 

;  Parameters;  NONE 


initmodule  cses  common 
ore  114h 

int5_offset  rw  1 
int5_sef:ment  rw  1 

cse? 

push  hx 
push  ax 

mov  hx .  offset  interruot_handler 

mov  ax .  0 

push  ds 

mov  ds ,  ax 

mov  ds  ; int5_off set ,  hi 

mov  tx ,  cs 

mov  ds  ;lnt5_seement ,  hx 

pop  ds 

pop  ax 

pop  hx 

sti 

ret 


enahle_cpu_in ter runt  s ; 

;  Module  Interface  Snecification : 

;  Caller;  Ether  test ( PL/I )  Procedure 

;  Parameters:  NONE 

sti 

ret 


;  ««:(c:4c:;c:9c:4c4c:;e:;c:;c:tc :;c#«:4c:Ct  1(1 


Module  Interface  Specification 


;  Caller:  Ethertest (PL/I )  Procedure 

♦  Parameters:  none 

cli 

ret 


interrupt_handler : 


*  IP,  CS,  and  fla^s  are  already  on  stack 
;  save  all  other  resisters 

push  ax 
push  bx 
push  cx 
push  dx 
push  si 
push  dl 
push  hp 
push  ds 
push  es 

call  hl_interrupt_handler 

♦  hlsh  level  source  routine 
;  In  Ethertest  Module  (PL/I) 

*  restore  registers 


pop 

es 

pop 

ds 

pop 

hp 

pop 

dl 

pou 

si 

poo 

dx 

pop 

cx 

pou 

hx 

pop 

ax 

St  i 

iret 

end 


*  aATEMOD  /  GATETRC  Eile  (JATEM/T.aSe  BREWER  1  SEP  84  -/ 

- -iff 

*  This  module  is  given  to  the  user  in  oId.1  form  to  linic  */ 
’S'  with  his  initial  and  process  modules.  Any  changes  to  */ 

user  services  available  from  the  OS  must  be  reflected  **“/ 

*  here.  In  this  way  the  user  need  not  be  concerned  with 

*  actual  GATEKEEPER  services  codes.  Two  lines  of  code  ’*'/ 

*  are  contained  in  conditional  assembly  statements  and 

*  control  the  output  to  be  GATE'IOD  or  GATETRC  depending  ’^Z 

*  on  the  value  of  GATEMOE  at  the  code  start.  ’*'/ 

<c - sic/ 

*  This  module  reconciles  parameter  passing  anomalies 

*  between  f^CORTEX  (written  in  PL/M)  and  user  programs 

*  (written  in  PL/I). 

>!c - s:c  / 

*  ni  calls  are  made  to  the  GATEKEEPEP  in  LEVEL2  of  the 

*  OS.  The  address  of  the  GATEKEEPER  must  be  given  below.*/ 

<S - -i:-  / 

*  The  ADD2BIT16  function  does  not  maice  calls  to  MCOPTSX.  */ 

*  It's  ourpose  is  to  allow  the  addition  of  two  unsigned  */ 

*  16  bit  numbers  from  PL/I  programs.  */ 

«:tC]i(Xc4c3(c:tc3gc3lc:tc>}c9;c>!c3iC];c3t:Xc:«E4<:{c3;c:jEXC3(e3(c:ic]ie«:ic4c:tc:;::4c;jc#s;c:ic:{c9;c4e9ie3tci;c:!e:(c:it>ic:ic:(c:ic9!c>i:siC3i:9;c:;c>!c:ic  / 


DSSG 


GATEMCD  SOU  0  ?***  SET  TC  ZERO  FOR  GATETRC 

SET  TO  ONF  FOR  GATEMOD 

PUBLIC  ADVANCE  ;***  THESE  DECLARATIONS  MAKE  THE 

PUBLIC  AWAIT  ;***  GATEKEEPER  FUNCTIONS  VISIBLE 

PUBLIC  CREATE  EVC  J***  TO  EXTERNAL  PROCESSES 

PUBLIC  CREATElPROC 

PUBLIC  CREATE  SEO 

PUBLIC  PREEMPT 

PUBLIC  READ 

PUBLIC  TICKET 

PUBLIC  DEFINE  CLUSTER 

PUBLIC  DISTRIBUTION_MA.P 

PUBLIC  ADD2BIT16 


AWAIT_IND  ECU  0 
ADVANCE_IND  EOU  1 
CRSATE_EVC_IND  EOU  2 
CF,EATE‘SEO_IND  ECU  3 
TICKET_IND  ECU  4 
READ  IND  EOU  5 


;***  THESE  APE  THE  IDENTIFICATION 
CODES  RECOGNIZED  BY  THE 
;***  GATEKEEPEr,  IN  LEVEL  II  CF 

mcortsx 


CREATE  PROC_IND  EOU  6 
PREEMPT_IND  EOU  7 
DEFINE_CLUSTEP_IND  EOU  9 
DISTRIBUTION  MAP  IND  EOU  9 


8B 


.  'v' 


r.  .’V'C ... 


r1 


IP  GATEMOD 

GATEKE5PSR_IP  DW  0036H 
GATEKEEPER_CS  0BADH 
ELSE 

GATEKEEPER_IP  DW  0068E  ;####  1  ####  <- 
GATEKEEPER_CS  DW  034CH  I  ####  2  <■ 
ENDIF 

GATEKEEPER  EOU  DWORD  PTR  GATSKSEPER_I P 
CSSG 


AWAIT  AWAIT  ’*'’*“*'  AWAIT  AWAIT 

AWAIT: 


PUSH  ES 
MOV  SI.2[BXl 
MOV  BX,[3X] 

MOV  AL.AWAIT_IND 
PUSH  AX 
MOV  AL,  [BX] 

PUSH  AX 
MOV  AX,  [SI] 

POSH  AX 
PUSH  »X 
PUSH  AX 

CALL?  GATEKEEPER 
POP  ES 


;SI  <—  PNT  TO  COUN'T  AWAITED 
;BX  <--  PNT  TO  NAME  OF  EVENT 

;N  < —  AWAIT  INDICATOR 

;BYT  < —  NAME  OP  EVENT 
;AX  <—  COUNT  AWAITED 
; WORDS  <--  COUNT  AWAITED 
;PTR  SEG  UNUSED  WORD 
;PTR'OFPSET  <-”UNUSSD  WORD 


advance  **’*'  ADVANCE  ADVANCE  ADVANCE  #*»;«»!«/ 


ADVANCE: 

PUSH  ES 
MOV  BX.  [BX] 

MOV  AL, ADVANCE_IND 
PUSH  AX 
MOV  AL, [BX] 

PUSH  AX 
PUSH  AX 
POSH  AX 
PUSH  AX 

CALLF  GATEKEEPER 
POP  ES 


;BX  <--  PTR  TO  NAME  OP  EVENT 

;N  < —  ADVANCE  INDICATER 

;BTT  < —  NAME  OF  EVENT 
;WORDS  <—  UNUSED  WORD 
•  PTR_SEG  <"  UNUSED  WORD 
;PTR  OFFSET  < — UNUSED  WORD 


C5EATE_EVC  CEEATE_EVC  CREATE_EVC 

CREATE_E¥C: 

PUSH  ES 
MOV  BX, [BX] 

MOV  AL,CREATE_EVC  IND 
POSH  AX 
MOV  al.CbxI 
PUSH  AX 
PUSH  AX 
POSH  AX 
PUSH  AX 

CALLF  GATEKEEPER 
POP  ES 

RET 

.##-4!  CREATE_SEO  CREATE_SEO  =***  CREATS_SEO  / 

CREATE_SEO: 

PUSH  ES 
MOV  BX, [BX] 

MOV  AL. CREATE  SEO_IND 
PUSH  AX 
MOV  AL,[BXl 
PUSH  AX 
PUSH  AX 
PUSH  AX 
PUSH  AX 

CALLF  GATEKEEPER 
POP  ES 

RET 

TICKET  TICKET  *’***  TICKET  TICKET  ***  TICKET 
TICKET; 

PUSH  ES 

tjusR  ES  ;  TICKET  NUMBER  DUMMY  STORAGE 

MOV  CX,SP  JPOINTER  TO  TICKET  NUMBER 

MOV  BX,[BX1  ;EX  <—  ?TR  TO  TICKET  NAME 

MOV  AL,TICKET_IND 

PUSH  AX  ?N  <—  TICKET  INDICATER 

MOV  AL,  [BX] 

PUSH  AX  ;BYT  <--  TICKET  NAME 

PUSH  AX  ; WORDS  < —  UNUSED  WORD 

PUSH  SS  ;PTR  SEG  <—  TICKET  NUMBER  SEG 

PUSH  CX  ;PTR  OFFSET  TICKET  NUMBER  POINTER 


;BX  <—  PTR  TO  NAME  OF  SEO 

;N  < —  CREATE_SEO  INDICATER 

;BYT  < —  NAME  OF  SEO 
tWORDS  < —  UNUSED  WORD 
;PTH_SEG  <--  UNUSED  WORD 
;PTR  OFFSET  <— UNUSED  WORD 


;BX  <—  PTR  TO  NAME  OF  EVENT 

;N  < —  CREATE_EVC  INDICATOR 

;BYT  < —  NAME  OF  EVENT 
fWORDS  < —  UNUSED  WORD 
;PTR_SEG  < —  UNUSED  WORD 
;PTR  OFFSET  < — UNUSED  WORD 


CALLF  GATEKEEPER 

POP  BX  ;retrieve  ticket  number 

POP  ES 
RET 

;***  READ  READ  READ  READ  pEAD  READ 

READ: 

PUSH  ES 
PUSH  ES 
MOV  CX.S? 

MOV  BX.  [3X1 
MOV  AL,READ_IND 
PUSH  AX 
MOV  AL,[BXl 
PUSH  AX 
PUSH  AX 
PUSH  SS 
PUSH  CX 

CALLF  GATEKEEPER 
POP  BX 
POP  ES 

RET 

CPEATE_PROC  CREATE_PROC  CREATE_PROC  « -‘i* sit 

C?EATE_PROC : 

PUSH  ES 
MOV  SI.14[BX] 

PUSH  WOPD  PTR  [SI] 

MOV  SI,12[3X] 

PUSH  WORD  PTR  [SI] 

MOV  SI  .  l(?[BXl 
PUSH  WORD  PTR  [SI] 

MOV  SI,  9[3X] 

PUSH  WORD  PTE  [511 
MOV  SI.  6[BX] 

PUSH  WORD  PTR  [SI] 

MOV  SI ,  4r3Xl 
PUSH  WORD  PTR  [SI] 

MOV  SI,2[BXl 
MOV  AH,  [SI] 

MOV  SI , [BX] 

MOV  AL,  [SI] 

PUSH  AX 
MOV  CX.SP 

MOV  AL,CREATE_PP.OC  IND 
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;si  <—  PTR  TO  PROCESS  ES 

;STACK  PROCESS  ES 

;si  <—  PTR  TO  PROCESS  DS 

fSTACK  PROCESS  DS 

;SI  <—  PTR  TO  PROCESS  CS 

;STACK  PROCESS  CS 

;si  <--  PTR  TO  PROCESS  IP 

;ST»CK  PROCESS  IP 

;si  <—  PTR  TO  PROCESS  SS 

;STACK  PROCESS  SS 

;si  <—  PTR  TO  PROCESS  S? 

;STACK  PROCESS  S? 

fSI  <--  PTR  TO  PROCESS  PRIORITY 

;GST  PROCESS  PRIORITY 

;SI  <—  PTR  TO  PROCESS  ID 

fGET  PROCESS  ID 

;STACK  PROCESS  PRIORITY  AND  ID 
;POINTER  TO  DATA 


JEVENT  COUNT  DUMMY  STORAGE 
;POINTER  TO  EVENT  COUNT 
;BX  <—  PTR  TO  EVENT  NAME 

;N  < —  READ  INDICATSR 

;3YT  < —  EVANT  NAME 

;BYT  < —  UNUSED  WORD 

;PTR  SSG  <—  EVENT  COUNT  SEGMENT 

JPTR^OFFSET  <--EVENT  count  POINTER 

;retrieve  event  count 


PUSH  AX 
PUSH  AX 
PUSH  AX 
PUSH  SS 
PUSH  CX 

CALLF  GATEKEEPER 
ADD  SP,14 
POP  ES 


;N  < —  CREATE  PROCESS  IND 
;BYT  < —  UNUSED  WORD 
;WORDS  <—  UNUSED  WORD 
;PROC_PTR  SEGMENT  <—  STACK  SSG 
;PROC_PTR  OFFSET  <—  DATA  POINTER 

;REM0VE  STACKED  DATA 


PREEMPT  PREEMPT 


PREEMPT: 


PUSH  ES 
MOV  BX.  [BX] 

MOV  AL ,PRESMPT_IND 
PUSH  AX 
MOV  AL. [BX] 

PUSH  AX 
PUSH  AX 
PUSH  AX 
PUSH  AX 

CALIF  GATEKEEPER 
POP  ES 


;BX  <--  PTR  TO  NAME  OF  PROCESS 

;N  < —  PREEMPT  INDICATER 

;BYTE  <—  PREEMPT  PROCESS  NAME 
;WORDS  <--  UNUSED  WORE 
;PTR_SEG  <—  UNUSED  WORD 
;?TR  OFFSET  <—  UNUSED  WORD 


DEFINE  CLUSTER 


DEFINE  CLUSTER 


DEFINE  CLUSTER; 


PUSH  ES 

MOV  BX,  [BX]  ;BX  <--  PTR  TO  LOCAL$CLUSTER$ADDR 

MOV  AL,  DEFINE_CLUSTFP._rND 

PUSH  AX  ;N  < —  DEFINE  CLUSTER_IND 

PUSH  AX  ;3YT  <--  UNUSED  WCRD 

PUSH  WORD  PTR  [BX]  ?  WORDS  <—  LOC  ALACLUSTIRS  ADDR 

PUSH  AX  ;PTR_SEG  <--  UNUSED  WORD 

PUSH  AX  ;PTH_OFFSST  <—  UNUSED  *CRD 

CALLF  GATEKEEPER 
POP  ES 


***  DISTRIBUTION_MAP  ***  DISTRISUTON  MAP 


DISTPIBUTION_MAP: 

PUSH 

ES 

MOV 

SI,  4[BXl 

;SI  <—  PTR  TO  GROUP  .ADDRESS 

PUSH 

'4/ORD  PTR  [SI] 

; STACK  THE  GROUP  ADDRESS 

MOV 

SI,  2[3X] 

fSI  <--  PTR  TO  ID  OF  MA?_TYPE 

MOV 

AH,  [SI] 

MOV 

SI,  [BX] 

;SI  <—  PTR  TO  MAP  TYPE 

MOV 

AL,  [sn 

;AL  <--  MAP  TYPE 

PUSH 

AX 

;STACK  ID  AND  MAP  TYPE 

MOV 

CX,  SP 

; POINTER  TO  DATA 

MOV 

AL,  DISTRIBUTION 

MAP  IND 

PUSH 

AX 

;N  < —  DISTP.IB  MAP  IND 

PUSH 

AX 

;PYT  < —  UNUSED  WORD 

PUSH 

AX 

;WORD  <—  UNUSED  WORD 

PUSH 

ss 

;MAP  PTR  SEG  <--  SS 

PUSH 

CX 

;MAP  PTR  OFFSET  <—  DATA  PTR 

CALLE 

■  GATEKEEPER 

ADD 

SP,  4 

POP 

ES 

RET 

;«=!'>!'  ADD2BITie  ADD2PIT16  *=‘=’5'  ADD2BIT16  ADD2BIT16 


ABD21IT16: 


MOV  SI,  [3X1 
MOV  EX.2[PX] 
MOV  SX.rSXl 
ADD  BX.fSIl 


;SI  <--  PTP.  TO  3IT(16)#1 
;EX  <--  PTR  TO  BIT(16)#2 
;BX  <--  BIT(16)#2 
;BX  <—  BIT(16)#1  +  3IT(16)i‘2 


RTT 


END 


APPENDIX  E 

THE  DEMONSTRATION  PROGRAM 


The  demonstration  program  is  a  combination  of  four 
modules  that  simulate  gathering  and  processing  track 
information  and  calculating  direction  and  launcher  number 
for  missile  launchers. 

It  was  not  a  goal  of  this  demonstration  program  to 
provide  a  valid  algorithm  for  a  real  system,  but  rather  to 
show  the  synchronization  of  distributed  asynchronous 
processes  with  different  execution  times,  working  with 
different  length  shared  data  queues,  that  reside  at 
different  addresses  at  different  clusters.  Another  goal  was 
to  demonstrate  the  systems  ability  for  processes  working  in 
shared  buffers,  or  with  local  copies  of  shared  data  items, 
or  a  combination  of  both. 

Process  trkdetec  simulates  the  track  detection  by 
producing  x,  y,  and  z  track  data.  The  track  information  is 
put  into  the  50  slot  queue  TRACK. 

Process  trkrprt  simulates  the  track  movement  calculation 
by  producing  dx,  dy,  and  dz  values  from  the  comparison  of 
two  consecutive  track  informations.  It  consumes  TRACK  data 
and  puts  delta  information  into  the  20  slot  queue  DELTA. 

Process  mslorder  simulates  the  missile  launcher 
direction  calculation.  It  consumes  TRACK  data  and  DELTA  data 
and  combines  these  into  simulated  azimuth  and  elevation 
information  and  assigns  a  launcher.  These  data  are  put  into 
the  50  slot  queue  MISSILE_ORDER. 

Process  msltrain  simulates  the  missile  launcher  training 
by  consuming  MISSILE_ORDER  data  and  displaying  launcher 
number,  launch  number,  azimuth,  and  elevation. 

For  demonstration  purposes  each  process  displays  its 
calculated  values  and  its  status  (e.g.  waiting,  going,  done, 


queue  full,  etc.) 

The  program  was  successfully  run  in  three  different 
constellations : 

1. )  Process  trkdetec  and  process  msltrain  multiplexed  on 
one  SBC,  and  process  trkrprt  and  process  mslorder 
multiplexed  on  a  second  SBC  in  the  same  cluster  (cluster  2). 

2. )  Process  trkdetec  and  process  msltrain  multiplexed  on 
one  SBC  in  cluster  1,  and  process  trkrprt  and  process 
mslorder  multiplexed  on  one  SBC  in  cluster  2. 

3. )  Process  trkdetec  on  one  SBC  and  process  msltrain  on 
another  SBC  in  cluster  1,  and  process  trkrprt  on  one  SBC  and 
process  mslorder  on  another  SBC  in  cluster  2. 

The  Link86  Input  option  was  used  to  link  cluinit , 
trkdetec,  msltrain,  and  gatemod  into  CIUSERS;  c2uinit , 
trkrprt,  mslorder,  and  gatemod  into  C2USERS  for 
constellation  1.)  and  2.). 

For  constellation  3.)  following  linkage  was  done: 

trkdinit,  trkdetec,  and  gatemod  into  TRACKER, 
msltinit,  msltrain,  and  gatemod  into  MSLREACT, 
trkrinit,  trkrprt  ,  and  gatemod  into  REPORTER,  and 
msloinit,  mslorder,  and  gatemod  into  MSLORD. 

This  demonstration  program,  even  though  done  by  one 
person,  was  built  under  a  simulated  lead  programmer  team 
policy.  The  lead  programmer  provided  the  system-wide  shared 
data  declaration,  the  system  definitions,  the  cluster 
specific  relation  data,  pointer  assignments,  and  systems 
initialization.  The  lead  programmer  also  decided  about  the 
distribution  of  the  different  modules  over  the  system. 

The  application  programmers  built  their  modules 
%including  the  share. del  and  pointer. ass  files. 


i)D-A164  86a  PROCESS  SVNCHR0N1Z8TI0N  AND  DATA  COHNUNICATION  BETUEEN  2/2 
PROCESSES  IN  REAL  TINE  LOCAL  AREA  NETUORKSCU)  NAVAL 
POSTGRADUATE  SCHOOL  HONTEREV  CA  R  HAEGER  DEC  65 

F/G  17/2 


UNCLASSIFIED 


NL 


Jtcjjcigci(()(c)ti3;c)tc];c  4(9(9  :;(>)(  :^>gc>;c9(e3je](c9tc3ic:^:(s  4c  Incite  9(e:tcit()tc4cjtat(]«c9je9ic](cXc3ie«4e  14c  Jtc9ic:4‘i(c3tc3jcXc:;c««:tc:(c4e:Ce«9«‘3t(  lit 


**>!'  CIUSDRS.INP  file 

4(4(4c - 4(4(4c 

4C4C4C  This  file  is  used  to  link  user  initialization, 

**♦  user  process  msltrain,  user  process  trkdetec,  and 
**’*'  ^atemodule  into  C1USERS.CMD,  the  executable  file 
multiplexing  the  two  user  processes  on  one  SBC. 


4!4«4t4(4c5:(4(9f«4'5!«4(':«4!4t5!'4es!t4t4!4«!!«4t4!4s4c49494t4t4t4e!C<4«4ts!s9:c4t4c4(4c4t>l'4t4t4ts!s4t’!'sit4«4t5!‘5i«#4t4c4t4«s!'>!! 


clusers  = 

cluini  t  [code  [ab  [439] ]  .data  [ab[800l  ,m  [0]  ,  ad  [82]  ]  .map  [all]  ]  , 
trkdetec , 
msltrain , 
gatemod 

9t:4e4e4(4c4(4e4(4c9E(4c4c9i(4c4c4c4c4:9(c4:4(90(4c4c4(4[4c4c4e4(4(4c4(4c4i4(4c4c4c4c4(4c4c4c4c4(4‘4(3(:4C4(4(4(4c4c4:#4:494c 

9i:4:4c4c4c9i;4c4c9(c4c4>4(4(4(4c4c494c4(4(4(4e4(4c4c4:4c4(4(9(:4c4(4(4:4c^4(:(‘^(>ic4(4c4(4<4:9;c4(4c4(4(4:>i‘3(‘494c4:4(4c4c4: 


9!(4.4c  CIUINIT.PLI  file 

9^  49 4c - }ie4(4c 

*4«4c  This  is  the  initialization  procedure  for  the  *** 

**’*'  multiplexed  user  constellation. 


4c  4c  4c  4(  4c  4(4!  4c  9(9  4: 4c  4c  4: 4:  lie  9(9  ((c  4<  4c  4c  49  9!c  4(  4949  4c  49499(9  49  49  9ic4c  4^4(4(4(4(4(49  4c  4949  4: 4c  49  494(4:49  4c  4(4:49  4c  4(4(4(49  9(9 


cl_users_ini t :  procedure  options  (main); 
^include  'sysdef  .pli  ' ; 


/«  begin  */ 

/*  trkdetec  */ 

call  create  proc  ('05'b4,  'fc'b4, 

'09eb'b4,  '0800  'b4,  '0029'b4, 
'0439 'b4,  '0800 'b4,  '0800 'b4); 

/*  msltrain 

call  create_proc  ('06'b4,  'fc'b4, 

'0a0b'b4,  '0800'b4,  '02'^5'b4, 
'0439'b4,  '0800  'b4.  '0800 'b4); 
call  await  {'fe'b4,  '01'b4); 
end  cl  users  ir.it; 


4c  49  4c  4c  4c  4: 4C  49  4!  4c  4c  919  4c  4c  4c  4: 49  4c  4c  4: 49 4c  4c  4c  4c  9(:  4!  4949  4949  4(4(4(4(4(49  4:49  4c  4949  4c  4c  4949  4c  4c  4c  49  49  4(4(4(4(4!  4c  49  49  4c 


i 


^3 

45 


f 


#«)C(aieaiea9e)iei(e>ic:e(3(e90e9)e:{c:{e:Ce>!c4e)Ce>;(9!;:Ce:^^««Xeate<(4<)(()t(aCe:tc:(e«)(esic:tc:{c4e3{e9(e:{e>t(:tc:{c:te:te;;c9{(#>!c9;e:(C9gc«:(c:!:Xe 

TRACKER.  I NP  file 

iCe^e - - - - - - - - - ate:tcal( 

***  This  file  is  used  to  link  trkietec  initialization,  ’*'** 

user  process  trkdetec,  and  ^atemcdule  into.  *’**’*' 

♦♦<e  traCKER.CMD,  the  executable  file  for  user  process 
***  trkdetec  in  the  non-multiplexed  constellation.  *** 

:gc3«!««:tc3jc«Xeatc:tE«:tc«:4c«:t:iie:(citc9;e««:t(«Kc«ite:te«««:4c«««igMtc>tc9lc>tc:tc:«e:ici4(i)c«>ie«:t()}C3t(^:t:Xe«atC3tc«Jte9)c 
^I*clClC0I*  ~ 

trkdinit  [code  [ah[439n  ,data  [ah[800]  ,m[0]  ,ai  [82]]  ,map[all]  ] 

trkdetec , 

ffatemod 

Xe  age :((:(( 4e ^  ^  « lie  ^  at: 99c  stc  :{(>:<#  3ii  3S(  4  Jtc  lie  #  4: 3jc:(c )je  jjc  3ic  ijctc  :tc  :tc  :jc  :(c :{( :ic  41  ^  :tc  :(c  :tc  Jic  3jc  4e  9ie  aje  aic  :ie !{c  :te  ate 

9(caic>)caicjgeate3ic3te:it3t(>;e««>ic3ic9,<::eeaie3}c3jc]tc](c4c39c>)c]tta)t]tejgc4eate]{ii(e:tc)teatc]jc39e9j(ajcijcait]t(itc)te34c:tc:(c3ge>!c«:tcaeea;e4:9(caic9!c:it9;c 

TRKDINIT. PLI  file 


***  This  is  the  initialization  procedure  for  user 
ajeaje#  procBSs  trkletec  in  the  non-multiplexed 
***  constellation. 

ate Xe  att  ate  aSeagtige  3):  ate  3(1  ajciejiott:;:  age  3ie  iterate  age  age  aje  ate  3te4c«ag(aiea{eijc««:te  age  ajt  ate  aic«aieaic]((«9t:«:teite3{c  age  :te#a;c:t!  ate  afcjcttaj:  age 
aje  ate  aje  a^!  aje  a.'e  a{e  aje  a;e  aje  ag:  age  a!e  a;:  aje  aie  aje  aje  a,*:  age  aie  a(e  age  a(<  ate  a{<  a(eaie  a(c  age  aje  aSeaje  aje  ate  ate  aje  ate  aje  ate  age  ale  age  aje  afe  ate  aje  ate  ate  a'.e  ate  afe  aje  aje  aie  a;e  aie  aje  age  a!e 

trkdinit:  procedure  options  (main); 

%include  'sysdef .pli 
/*  he«?ir  */ 

call  create  nroc  ('01'h4,  'fc'b4, 

'085d'b4,  '0800 'b4,  '0023 'b4, 
'0439'b4,  '0800'b4,  '0800'b4); 
call  await  ('fe'b4,  '31 'b4); 

end  trkdinit; 

age  age  a(e  age  ate  age  ate  age  age  age  age  age  age  age  ate  aje  age  age  age  ate  ageage  age  age  a(e  age  ate  a(e  age  age  age  ageage  age  ate  ate  age  age  ate  ate  age  age  ate  age  age  age  ate  ate  age  age  age  a(e  ate  3(e  age  ajeajeaje  age  age 
age  afe  age  age  age  age  age  age  age  age  age  a(e  at:  ate  ate  age  age  Xe  ate  age  age  ate  age  ate  age  age  ateageage  age  age  ageage  age  age  age  age  ateageageate  age  ate  age  age  age  age  age  age  ate  ate  age  age  age  age  age  age  age  age  age 

***  MSLREACT.INP  file 

***  This  file  is  used  to  link  msltrain  initialization, 
user  orocess  msltrain,  and  ^atemodule  into 
MSLREACT.CMD,  the  executable  file  for  user  process 
*****  msltrain  in  the  non-multiplexed  constellation.  *** 

ate  age  age  Xe  age  X:  age  a(e  age  age  age  age  age  Xe  at:  :ge  age  a(e  af:  age  age  age  Xe  age  age  age  age  age  age  age  age  age  Xe  Xe  age  age  ate  age  age  age  age  age  ate  ageage  age  age  age  age  a,t  age  age  age  age  ate  age  age  age  Xe  age 

mslreact  = 

msl t ini t  [code [a b [439] ], data [ab [830] ,m [0] ,ad [82] 1 ,man [a 111  1 , 

msltrain , 

satemod 


"t  *  .V  ■ 


)Cc:C(aO(9jci(ti(‘>i(9it9e(Xt«4‘»>ic«9icX::((^:(e:((«9tc>9<:(c4>:t‘^3et:ic«:4t3)e]C(i(c«4(9ti^Xt:t(3t‘4‘«3tc:e>3C(4i4c««:t(3C‘««:(c«3te4c« 

***  MSLTINIT.PLI  file  *** 

^ijogc - - — - - 

*’*'*  This  is  the  initialization  procedure  for  user 
***  process  nsltrain  in  the  non-multiplexed 
constellation. 

msltinit:  procedure  options  (main); 

%include  'sysdef .pli ' » 

he^in  >«'/ 

call  create_'Droc  ('02'h4,  'fc'b4, 

'0825'b4,  '0«00'b4,  '0023'b4, 

'0439'b4,  '?800'b4,  '0800'b4); 

call  await  ('fe'b4,  '01'b4); 
end  msltinit; 

« ]tc:tcXe:^:{c Jic:lt3ic:jc:(c:^^Xc#3tC3tc4eXC3)t^3(c4t;ic:{c:4c:((«:4c:tt:j:  4c 

4c  sic  4c  3(c  4c :;e  4e  ^  4c  4s  4c  4c  4c  4: 4e  4e  4c  4;  Jie  3ic  4c  4c  9^  4<  9ic  ^  He  4c  4: 4c4i  ^  4c  4e  4c  3Si  9!c  4:  ^ 4c  #  4c  >!>  >!(  >!(  #  sjc  #  >r  4c  # ^  v  # 

TP.KDETEC.PLI  file  R.  Hae^er,  Dec  1985 

4c - 


R.  Hae,eer,  Dec  1985 


4:4c4:  This  is  the  PL/I-96  code  for  user  process  trsdetec. 

It  simulates  traclr  detection  by  incrementing  track  ’*'*’*' 
4e4«4<  position  values  every  iteration.  It  produces  shared 
data  TRACK. 

4c4s4c4c4c4c4c4c4c4c4c4c4‘4c4c4e4c4:4!4:4c4c4!4c4(4c4<4c4c4e4c4c4c4e4c4c4c4c4c4e4c4c4c4c4c4c4c4c4e4c4c4:4c4c4(4c4c4:4c4c 

4c4c4<4c4c4c4c4c4c4c4e4c4c4c4c4:4c4c4c4c4c4e4c4‘4c4c4(4c4c4c4c4c4c4c4c4(4c4c4(4c4‘4c4c4c4c4c4c4c4c4c4(4c4c4c4c4!4c4c4c4e 

trkdetect:  procedure  ; 


by  32767. 
by  '0001  b4, 


^replace 

infinity 
one 
to  len 

%include  'sysdef .pli '; 
%include  'share. del'; 


/*  used  shared  data: 

1  track(0:49)  based( tr_ptr ) , 
2  X  fixed  bin  (15) . 

2  y  fixed  tin  (15) , 

2  z  fixed  bin  (15) ,  */ 


DEC LABE 

i  fixed  bin  (15), 

(k, tq_ub, ta_lb)  bit  (16), 

1  local_traclc, 

2  X  fixed  bin  (15), 

2  y  fixed  bin  (15) , 

2  z  fixed  bin  (15); 

/*  main 

%include  'pointer. ass 

do  i  =  0  to  infinity; 

/<«  simulation  of  track  input  data 
1 oca l_t rack. x=i+i; 
local_track.y=i+10; 
local_track.z=i+i; 

put  track  in  shared  memory 
track(‘nod(  i  ,talen  ) )  =  local_track; 
call  advance  (TRACK_IN); 
tq_ub  =  read( TRACK_IN ) ; 

/♦  display  track  values  */ 

put  skip(2)  edit  ('Track  ',binary( to_ub) , 

'  x:  ', local_track.x, 

'  y:  ', local”track .y , 

'  z:  ',local“track.z , 

'  put  in  queue  slot  ' ,mod { i , tolen ) ) 
(4(a,f(5) ) ) ; 

tq_lb  =  read  (TRACK_ODT); 
report  status  */ 

put  skip(2)  edit ('Last  consumed  track  ' , binary( to_lb ) , 
'  in  slot:  '  .mod  ( biT'.ary(  tq_lb  )-l ,  to  len  )  ) 
(2(a,f (5) )) ; 

/*  check  if  slot  available  for  next  iteration 
if  ( ( binary( ta_ub)-binary(to_lb) )  >=  tolen  )  then 
do ; 

k  =  add2bltl6( ta_lb,one); 

/*  report  status 

put  skip(2)  edit  ('Waiting  for  slot:  ', 

mod( binary( k )-l , tolen ) , 

'  to  be  consumed  ')  (a,f(3),a); 
call  await  (TRACE_0UT,  k); 
end; 

end;  /*  do  FOREVER 
end  trkdetect; 


99 


4c4(«4>«3CiX(«4t*4(4<#4c4c4c4t«4(««4‘4>««4E4i««4t4t4n«t4i4i«>t<4(»>ti4i««at>4>>t<4<9t>4i3t(4»|c«4(»«3(t««4> 


**♦  MSLTRAIN.PLI  file  R.  Hae^er,  Dec  1985 

4c4>4t _ - - - - 


***  This  is  the  PL/I-86  code  for  user  process  frisltrain. 

It  simulates  missile  launcher  training  hy  • 
displaying  launcher  assignment  and  direction  values.  *’*'’*' 
***  It  consumes  shared  data  MISSI LE_ORDER . 

4s  4(4: 4:4(4: sic 

4(  4(  4: 4(  4: 4: 4(  4: 4: 4: 4: 4: 4C  4: 4: 4: 4: 4: 4: 4: 4=41 4:  :}!4(  4(4:4: 4: 4:4: 4:4: 4: 4:4:4: 4: 4:4: 4:  Sit  4: 4: 4: 4: 4: 4: 4: 4c  4(4(4: 4c  4: 4:4(4:39:4: 


msltrain:  procedure  ; 

^replace 

infinity  hy  32767, 

one  hy  '0001 'h4, 

moqlen  by  50? 

%includ9  'sysdef .uli  '  J 
%include  'share. del'; 

/*  used  shared  data: 

1  missile_order (0:49)  based (mo_ptr ) , 

2  launcher  fixed  bin  (7), 

2  azimuth  float  binary, 

2  elevation  float  binary,  */ 

DECLARE 

i  fixed  bin  (15), 

R  bit  (16)  static  init  ('0000'b4); 

/*  end  DECLARATIONS  ’*'/ 

/”*  main 

%include  'pointer .ass '; 

do  i  =  0  to  infinity; 
k  =  add2bitl6(k,  one); 

/ss  report  status  */ 
put  skip  list ( 'msltrain  waiting'); 
call  await  (MISS ILE_ORDER_IN.  k); 

consume  and  display  missile  order  values  ♦/ 
put  skip(2)  edit ( 'launcher:  ', 

misslle_orler'mod(i,moalen) ) .launcher, 
launch:  ',binary^k), 
azimuth:  ', 

missile_or4er(mod(ivmoalen) ) .azimuth, 

'  elevation:  ', 

missile  order (mod ( i .moqlen ) ) .elevation) 
(2(a,fr5) ),2fa,e(10,2)) ); 


100 


call  alvance  (MISSILE_0RI3ER_0UT  ) ; 
end?  /*  do  i  */ 
end  msltrainJ 


»««««:(( >ic:;(«:tc:tc«itc]ecXc>)(9ie:ec:(c4(««(«#3(>X(4(«]i(  41 3ic4C3tc«Xc3(c«VXe3t‘#iO(3t‘3(()i‘:;cX(9(C3t(3;e3i(39t3C(>S:9te3(c:ic«:tC3jc 


C2USEHS.INP  file  =«'»*"!' 

i(e9:c:{c. - - - - - 

sx##  This  file  is  used  to  link  user  initialization, 


>xjx>it  user  process  mslorler,  user  process  trkrprt,  and  =*=*=*' 
***  gatemodule  into  C2USERS.CMD,  the  executable  file 
*’*'*  multiplexing  the  two  user  processes  on  one  SBC. 

c2users  = 

c2uinit  [code  [ab[439l]  .data [ab [800]  .m[0]  , ad  [82]  1  ,map[ain  ]  , 

mslo  rder , 

trkrprt, 

satemod 

«^3ie^«#X(>X:X39(«3(cX<^>X3X«>ic3XV::X«3X>X:X3X3C»X3X3X:X:X#:X«^3X3X>X>X«3X9XaX9X:t:9X«>X:X>X^^3X3X4:aX««3X 

:ic:ec:«C3(cv3X^3X>X«]X3X3X3X3X3X«3X3X:X9X>XX:)X#3X3X9X^^3X#^iX3X>X^9X^^’X)X9X«>X:X>ic3X#>X»X^9::>X$3X'X 


**♦  C2UINIT.PLI  file 

### - - - - - ;):s(e# 

’X’xv  This  is  the  initialization  procedure  for  the 
***  multiplexed  user  constellation. 


;{{  jX  iX  « iX  ^  ){<  #  3X  ^  )X  )X  3X  sX  >!<  9X  iX  #  3^  #  ><<  3X  >!e  ^  )X  >!<  3X  #  =X  #  iX  #  >X  >!(  iX  iX  3X  »ic ’X  #  iX  ^  9i:  :X  »:c  si: 


r2_users_init ;  procedure  options  (main); 

:^include  'sysdef  .pli  ' ; 
be^ln  V 

/*  missile  order  */ 
call  create_oroc  ('03'b4,  'fc'c4, 

'0a29'b4,  VB00'b4,  'e029'b4, 
'0439 'b4,  '0800  'b4,  '0830  'b4); 

/*•  track  report  */ 
call  create_proc  ('04'b4,  'fc'b4, 

'0b47'b4,  '3P00'b4,  '0303'b4, 
'0439 'b4,  '0800  'b4,  '0800 'b4); 
call  await  ('fe'b4,  '01'b4); 
end  c2  users  init; 


:X3XX<:XiX3X9X>X3X<cX(>X>X>X3XiX:XiXiX)X>X9X3X>X3X3X]X3X>X)X3^3X<c9X)X3X)XaX9X3X3XiX3X3X3X:X>X9X’X3X:X3X3X3XiX>X3XiX3X# 


I 


a 


3ic:t(g{c:tEXe«:tt>iciicK(  4c  3tc«Xc  It:  4c  sec 

4c4c4t>;c4c4c9e:4c«9;:>x4c4c4c4c4c4c4c4c4c>ic4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4>4c4c4c4c4c4>4c4c4c4c4c4c4c4c4c4c4c]ec^:ec4c4<4c 
4C4C4C  REPORTER.  IN?  file 

4C4C4C - 4C4C4C 

***  This  file  is  used  to  liiilc  trlcrrrt  initialization, 

4c4c4c  user  process  trlcrprt ,  and  gatemodule  into  *** 

4t4c4c  reP0RTER.cmd,  the  eiecutahle  file  for  user  process 
4S4C4C  trlcrurt  in  the  non-multiplexed  constellation  *** 

:e!4c4c4c4e4'4:4s4c5!!4!5:ciCc4;:;s4!#45:;:4ts!t4c4s4e4c4c4c4c4c4c4'*4c#4t4cs!'4c4c4:4c4:4s4c4c4c4c4c4c4«4c4c4c5;tjic^s5',ss;t^ene 

reporter= 

trkrini t  [code [ah [439] ] .data [ah  [800] ,m  [0] ,ad [83] ] , mao [all] ] , 

trlcrprt , 

aatemod 

3e:4c9ic>Se4c4c4c4c4c4c4c4c4:4c4<4c4c4‘4c4‘4c4c4c4c4c4c4c4:4c4csic4c4c4c4c4c4c4c4:4‘4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c:;c4c 
sec  :CC  4c  4c  4c  4c  4c  4c  4c  4C  4c  4c  4C  4c  4c  4<  4c  4c  4c  4c  4c  3}:  4c  4c  4: 4c  4c  4c  4c  4c4c  4c  4: 4c  4c  4c  4: 4c  4c  4: 4c  4c  4c  4c  4c  4C4: 4c  4c  4c  4c  4c  4c  4c  4c  4c  4c  4: 
4C4C4C  TFKPINIT.PLI  file 

4t4'4c - 4C4C4: 

4c4‘4c  This  is  the  initialization  procedure  for  user 

4C4C4C  process  trkrort  in  the  non-mul tiplexed  constellation. 

4s4c!!c4c4t4c3:c4c4«:)c4c4'4s4c4«4c4c4c4s4s4c4c4c4c4c4c4c4c4c4c4c4c4c4'4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4e4c>;c4e,;t4ej;c4:4e4e4! 

trkrinit:  procedure  options  (main); 

^include  'sysdef .oli ' ; 

/=»  be^in  ♦/ 

call  create  oroc  ('04'h4,  'fc'h4, 

'037f'h4,  '0800 'h4,  '0023'b4, 

'0439'h4.  '?e'^e'h4,  '0800'b4); 

call  await  ('fe'h4,  '01 'h4); 
end  trkrinit; 

4c4c4c4c4c4c4c4c4c4c4c4‘4c4c4c4c4c4‘4c4c4c4c4c4c4c4c4c4c4c4c4c4c4!4c4c4c4c4c4c4c4c4:4c4c4c4c4c4c4c4:4c4c4c4c4c4c4c4:4:4c 
4c  4c  4c  4c  >!c  4s  4c  4*  4«  4«  4c  4=  4<  4c  4«  4c  4c  45  4s  4c  4' 4c  s^:  4c  4c  4c  4c  4c  4c  4;  4c  4c  4c  4t  4c  4c  4c  4s  4c  4c  4<  4t  4c  4c  4e  4c  3)t  sS  sjc  3js  4s  4s »;!  4e  4!  »;e  4;  :jt 

MSLORD.INP  file 

4‘4c4c - 4c4e4c 

4C4C4C  This  file  is  used  to  link  mslorder  initialization, 
user  process  nslorder,  and  ^atenodule  into 
I^SLORD  .C'lD ,  the  executable  file  for  user  process 
4t4c4c  rnslorder  in  the  non-multiplexed  constellation. 

4c4c4c4c4c4c4c4c4c4c4c4c4e4c4c4c4c4c4c4c4c4c4c4c4c4e4c4c4c4c4c4e4i4c4e4c4c4e4c4s4c4:4c4c4c4c4c4c4c4c4c4c4c4c4c4:4c4c4c4c 

mslord  = 

msloinit  [code  [ah  [439]  1  .data  [ah  [800]  ,m  [0]  ,ad  [82]]  ,mao[all]  ]  , 
mslorder , 

#>:atemod 

4i4i4c4c4c4c4e4c4c4>4c4c4c4c4c4‘4c4c4:4c4‘4c4c4c4c4c4c4c4c4c4‘4c4c4c4c4c«4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c4c 


WWW 


)fc  4c  :(c:(e:(eX(#3tc  <(«)(:  :(<:((>)<>(<  lie  )«(«](< 


**♦  MSLOINIT.PLI  file  ’«'*« 

4>4ci(c.-~ _ _ _ — _ — - 


***  This  file  is  the  ir.tlalization  procedure  for  user  ’*'*=*' 
***  process  nslorder  ia  the  noa-uultiplezed  coastellation*** 

4:4c>)c4c4c4(4:iiic9;(4;4c4c4:4c4e4c4(](C9!e4c4c4c4C](t4[4c4i4i4:4t4c4t4c]{(4i4t4e4e4c>icaCc4i9ec4c4c4(4(4c4(Xc4c4c4c4i4caCcv4c4(4c 

msloinit:  procedure  options  (main); 

^include  'sysdef  .pli  ' ; 


/’S'  be^in  ’«'/ 

call  create_proc  ('03'b4,  'fc'b4, 

'09b3'b4,  '5'eP0'b4,  '0023 'b4, 
'0439'b4,  '0800'b4,  '0800'b4); 

call  await  ('fe'b4,  '01'b4); 
end  msloinit; 


#4«jJt4cs:<#3C;>:«##J!c*J!e4‘«#4c#>!'4t«>)t’!«4!4«3S'>)<4«35t4t4‘4c4tsit4«4e#4cs«t#4t4‘>i‘#4t4‘4t5St4t5it#:;«ie5ft4c#s)'!it*!{' 

4cilc«4c«4>4E«Xci;c4c>><4‘«4i4:4c4c>ec)t>4t3(<4c4c4(4c4c4‘4c4(4c4c4c>(i4c«4c>tc4c«3(c)tc4(>4c4c4c«4c4c>!(«>!c4c4c>e‘#4c4c>!(4c 


TRKRPRT.PLI  file  R.  Hae«er,  Dec  1935  *’!'* 

sSc## _ 


’"’S'*  This  is  the  PL/I-96  code  for  user  process  trierprt. 

’*'’*'*  It  simulates  computation  of  delta  values  for  tracks 
bv  comparing  two  consecutive  positions  of  a  track. 

4t4«4«  It  consumes  shared  data  TRACS  and  .reduces  shared 
data  DELTA. 

4e  4: 4c  ):t  9;c  4(  4c  41 4c  4c  4c  4i  4c  4<  #  4e  41 41 4:  4i  4c  9tc  4c  4(  #  4c  :{( y,:  4c  4c  4c  4: 4c  4c  4( /c  ^  4c  4c  4c  ’ic  4: 4c  4: 4c  #  >;c  4c 

trkrprt:  procedure  ; 

^replace 


infinity 

by 

32767, 

one 

by 

'0001'b4, 

do  len 

by 

20, 

to  len 

by 

50; 

^include  'sysdef .pli ' ; 

SSinclude  'share. del '; 

/*  used  shared  data: 

1  track(0:49)  basedf tr_ptr ) , 
2  X  fixed  bin  ( 15) , 

2  y  fixed  bln  ( 15) , 

2  z  fixed  bln  ( 15) , 


4C4C4C 
4:4C4C 
4c  4c  eje 
4C4C4C 
4C4C4C 


1  delta(0:19)  based ( de_ptr ) , 

2  dx  fixed  bin  (7 ) , 

2  dy  fixed  bln  (7) , 

2  dz  fixed  bin  (7) ,  */ 

DECLARE 

i  fixed  bin  (15), 

{km,lc)  bit  (16)  static  init  ('0000'b4). 

(lq_ub,dQ_lb)  bit  (16), 

1  local_traclc , 

2  X  fixed  bin  (15) , 

2  y  fixed  bin  (15), 

'waiting  for  slot  ', 
mod  (binary  (Ic  )-l  ,dq  len  ) , 

'  to  be  con  2  dy  fixed  bin  (7), 

2  dz  fixed  bin  (7) ; 

/*  end  DECLARATIONS  #/ 

/*  main  */ 

%lnclude  'poi nter . ass  ' J 

do  i  =  0  to  infinity? 

/’*'  report  status  */ 

put  slcip(2)  list  ( 'proc  trlrrprt,  iteration:  ', 

i, '  wait ' ) ? 

Itm  =  add2b itl6(km ,  one)? 
call  await  (TRACS  IN,  km)? 

/<'  report  status 
put  1 ist (  '  eoing  ' ) ? 

/’*'  read  shared  data  item  and  compute  delta  values  ’*'/ 

local_delta .dx=( track (mod (i.tolen) ) .i)-(local_track.x)? 
local _delta.ly=' track (mod ( 1 , talen ) ) .y )-( local_ t  rack .y ) ? 

1 ocal_delt  a.dz  =  ' t rack(mod (i, to len) ) .z )-(local_track.z)? 

/’>'  display  computed  delta  values  */ 
put  skip  list(  '  dx: ',local_delta .dx, 

'  dy: ', local_delta .dy, 
dz : ' ,local_delta  .dz  )  ? 

/*  save  track  data  for  next  Iteration  ♦/ 

1  ocal_t rack=  t rack (m odd, talen)  )  ? 

/*  put  delta  in  shared  memory  ♦/ 
delta (mod ( 1 ,dqlen ) ) =local  delta? 


call  advance(DSLTA_IN) ; 

/♦  report  status  =“/ 
out  list (  '  done  ' )  J 

iQ_ub=reai (DELTA_IN ) ; 
dq_lb=read ( DELTA_0aT ) ; 

/*  checlc  if  slot  available  for  next  iteration  */ 
if  ( (binary(ia_ub)-binary(dq_lb) )  >=  dqlen)  then 
do ; 

k=adl2bi tl6(do_lb ,one); 

/*  if  queue  is  full,  report  status 
put  slcip(2)  editC'Delta  queue  full,  ', 

'waiting  for  slot  ', 
mod  (binary!  It  )-l  .dqlen) , 
to  be  consumed') 

(a ,a ,f (3  ) ,  a ) ; 

call  await{DELTA_OUT,k) ; 
end ; 

end;  /*  do  i  ’V 


end  trkrnrt; 


:tc  ])t ijc  #  ^  sic  :(e  ^ ^  :;c  .Jc  3ic)^  :!( ^  91:  >!(  sic  #  4c  ^  ^  :(c  ijc  aj:  >Sc  34c  #  ^  ^  ^  >i:  # 

sjc  4c  stc  sg:  :4c  sjc  sic  sic  sjc  sOc  # :(( 4c  sec  sic  sx  34c  3(c  sic  itc sje  sjc  sjc  s;c :(( sjcsie « s4c  3(c){c  4c  :4c  4c  stc  igc  sic  :(c  4:  sjc  sje  i(c  s)c  sjc  S4C  age  >ie  sgc  sjc  sjc  sjc  sjc  4c  ife  sic  3tc )(:  sgc^c 

MSLORDER.PLI  file  R.  Haeger,  Dec  1965 

s;c4c>;c _ _  — - - - - - — - - - -  - - - - — - __4c3(cs;c 

4«4«>sc  This  is  the  PL/I-36  code  for  user  process  mslorder.  *’*'=*' 

***  It  simulates  computation  of  missile  launcher 
4c5!c4s  direction  and  launcher  assignment.  *** 

It  consumes  shared  data  TRACK  and  DELTA,  and  *’*'=*' 

uroduces  shared  data  MISSILS_ORDER. 

4e:i:4csi:4c:{csi:sicsi;s;:34s:;c4;4csiesic4:s!c34e4cst:4esics(c4c3!c4tsics4c4e4c4c4csic4e  S;;4c9ics;:s;e4c4cs;:s;es{cs;:4e34c4c4:si:si:4c4c4csie;ic4;si:::: 


mslorder:  procedure  ♦ 


:fereplace 


infinity 
one 
tq  len 
dq  len 
moolen 


by  32767. 
by  '0001'b4, 
by  50 , 
by  20, 
by  50 ; 


^include  'sysdef .pli 
^include  'share. del'; 


used  shared  lata: 

1  track(0:49)  based ( tr_ptr ) , 

2  X  fixed  bin  (15), 

2  y  fixed  bin  (15 ) , 

2  2  fixed  bin  ( 15) , 

1  delta(0:19)  based (de_ptr ) , 

2  dx  fixed  bin  (7 ) , 

2  dy  fixed  bin  ( 7) , 

2  dz  fixed  bin  (7) , 

1  rT)issile_order(0  :49)  based  (mo_ptr  ) , 
2  launcher  fixed  bin  (7), 

2  azimuth  float  binary, 

2  elevation  float  binary,  */ 

DEC LABE 

i  fixed  bin  ( 15) , 

km  bit  (16)  static  init  ('0000'b4), 

ki  bit  (16)  static  init  ('0000'b4), 

(moa_ub,moq_lb )  bit  (16), 

1  local_track, 

2  X  fixed  bin  (15)  , 

2  y  fixed  bin  (15)  , 

2  2  fixed  bin  (15)  , 

1  local_delta, 

2  dx  fixed  bin  (7 ) , 

2  dy  fixed  bin  (7) , 

2  d  2  fixed  bin  (7 ) , 

1  local_order, 

2  launcher  fixed  bin  (7), 

2  azimuth  float  binary, 

2  elevation  float  binary? 

/«  end  DECLARATIONS  «/ 

/*  main  */ 

^include  'pointer .ass '? 
do  i  =  0  to  infinity? 

/*  report  status  ’*'/ 

put  skip(2)  list('proc  mslorder,  iteration;  ', 

i , '  m_wai ting  ' )  ? 

kd=add2bi tl 6(kd , one ) ? 
call  awai t ( DSLTA_IN , kd  ) ; 


/*  report  status  */ 
put  llst('  'T  goine  '); 

/*  copy  track  values  ♦/ 

1 0 cal _ t ra ck= track (mod ( i  ,ta len  )  ) » 
call  advance(TP.ACK_OUT); 

/*  cooy  delta  values  */ 
local_delta=delta (mod( i .dolen ) ) ; 
call  advance(DELT.A_OUT )  i 
/*  display  track  values”*/ 

put  sUip  list!'  x:  ' ,  local_track .X ,  '  y : '  ,local_track .y , 

z :  ' .local_track . z ) ; 

/*  assign  launcher  */ 
local _order .launcher=mod (i ,4)+i; 

/*  simulate  direction  comuutation  */ 
local _order .a  zimuth= 

atand  (  float  ( localtrack.y  +  local  el  ta  .  ay )  / 
f loat ( local_track .X  +  local_delta  .dx ) J  ; 
local_order  .elevation= 

atand( float ( local_track . z  +  local  delta  .Iz  )/ 
float (local_track  .X  +  local_iel ta  .dx )  ) ; 
/*  put  missile  order  in  shared  memory  */ 
missile_order(mod(i.moqlen))=local_orderJ 
/*  display  missile  order  values  */ 
put  skip  list('  1:  '  ,local_or4er. launcher , 

a :  ' , loca l_o rder • az imu th , 
e: local'order .elevati on  ) ; 
call  advance(MISSILE_ORDrR_IN ) ; 

/*  report  status  */ 
put  li St (  '  m_done  ' )  ? 

moa_ub  =  read(MISSILE  0RDER_IN); 
moq_lb  =  read  ( MISS ILE_CRrER_CUT ) ; 

/*  check  if  slot  available  for  next  ireration  */ 
if  (  (  bina  ry  i  moa_ub  )-binary(nioo_lb  )  )>=moalen  )  then 
do ; 

km  =  add2bitl6(moQ_lb , one  ) ; 

/*  report  if  queue  is  full  */ 
put  skip^2)  edit ( 'Mis5ile_order  queue  full, 

'waiting  for  slot 
m od {binary' km )-l,moalen), 
to  be  consumed') 

(a,a,f(3),a)» 

call  await  (MISSILE  ORDER  OUT,  km); 

end; 

end;  /*  do  i  */ 
end  mslorder; 


K«  >(<  !(e  #  >!c  #  Jit  #  jjcjt  *  jx  #  5*  at 


APPENDIX  F 

SYSTEM  INITIALIZATION 

To  switch  on  and  initialize  the  system,  follow  these 
steps : 

(1) 

Switch  on  and  set  up  the  hardware  components  of  both 
clusters  in  accordance  with  the  respective  power  on 
procedures  described  in  the  AEGIS  lab  up  to  the  point  where 
the  system  disks  are  in  their  drives  and  the  reset  button  of 
the  MULTIBUS  frame  was  pushed. 

(2) 

Insert  MCORTEX  disks  for  cluster  1  and  cluster  2  in 
their  respective  drives. 

(3) 

For  cluster  1: 

At  terminal  1  type  in:  capital  'U' . 

After  prompt  type  in:  'gffd4:4'  followed  by  RETURN. 

After  prompt  choose  console  and  login  disk  'B'. 

After  prompt  B>  change  to  disk  A. 

After  prompt  A>  type  in:  'Idcpm'. 

After  prompt  A>  type  in:  'Idboot'. 

After  prompt  A>  change  to  disk  B. 

After  prompt  B>  terminal  1  is  ready  for  MCORTEX. 

At  terminal  2  type  in:  capital  ’U' . 

After  prompt  type  in:  'ge000:400'. 

After  prompt  choose  console  '2'  and  login  disk  'C. 

After  prompt  C>  change  to  disk  B. 

After  prompt  B>  terminal  2  is  ready  for  MCORTEX. 

At  terminal  3  type  in:  capital  'U' . 


After  prompt  type  in:  'ge000:400'. 

After  prompt  choose  console  '3'  and  login  disk  'D' . 

After  prompt  D>  change  to  disk  B. 

After  prompt  B>  terminal  3  is  ready  for  MCORTEX. 

For  cluster  2: 

At  terminal  1  type  in:  capital  'U' . 

After  prompt  type  in:  'gffd4:0'. 

After  prompt  do  the  same  as  in  cluster  1  after  this 
step . 

Make  sure  cluster  1  is  connected  to  the  RTC*  Ethernet. 
System  is  ready  for  MCORTEX. 

At  cluster  1; 

At  terminal  1  type  in:  ’MCORTEX'  followed  by  RETURN. 
System  will  ask  for  global  memory  to  be  loaded,  type  in; 
'Y'  and  hit  RETURN. 

System  will  ask  for  filename. 

At  terminal  2  type  in:  ’MCORTEX’  followed  by  RETURN. 
System  will  ask  for  global  memory  to  be  loaded,  hit 
RETURN. 

System  will  ask  for  filename. 

At  terminal  3  do  the  same  as  at  terminal  2. 

Cluster  1  is  ready  for  initialization. 

At  terminal  1  type  in:  ’C1PR0C.CMD'  and  hit  RETURN. 

The  driver  will  prompt  with  length  of  longest  queue,  and 
signal  that  cluster  1  is  initialized. 

Cluster  1  is  ready  for  the  application  processes. 

Initialize  cluster  2  the  same  way  as  cluster  1,  but  type 
in;  ’C2PR0C.CMD'  instead  of  'C1PR0C.CMD’. 

After  driver  prompts,  the  system  is  ready  for 
application  processes. 


Following,  the  initialization  of  the  demonstration 
program's  non-multiplexed  constellation  is  described. 

At  cluster  2: 

At  terminal  2  type  in:  ’MSLORD.CMD'. 

User  process  MSLORDER  will  start  executing. 

At  terminal  3  type  in:  'REPORTER.CMD'. 

User  process  TRKRPRT  will  start  executing. 

At  cluster  1: 

At  terminal  3  type  in:  'MSLREACT.CMD'. 

User  process  MSLTRAIN  will  start  executing. 

At  terminal  2  type  in:  'TRACKER.CMD'. 

User  process  TRKDETEC  will  start  executing. 

The  total  system  will  run. 

Every  terminal  displays  respective  data  on  its  screen. 
Terminals  1  in  both  clusters  show  message  exchange 
activity  'transmitting'  or  'receiving'. 

To  stop  any  process,  hit  'Control  S'  at  the  respective 
terminal.  To  restart  the  process  hit  'Control  S'  again. 
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